@htekdev/actions-debugger 1.0.114 → 1.0.116

package/errors/silent-failures/windows-11-arm-bash-shell-intermittent-zero-output.yml

@@ -0,0 +1,99 @@
+id: silent-failures-106
+title: 'windows-11-arm shell: bash Steps Intermittently Produce Zero Output and Exit 0'
+category: silent-failures
+severity: silent-failure
+tags:
+  - windows-11-arm
+  - bash
+  - composite-action
+  - arm64
+  - wow64
+  - silent-failure
+  - intermittent
+patterns:
+  - regex: 'error: no such command: `[a-z]'
+    flags: 'i'
+  - regex: 'error: no such subcommand: `[a-z]'
+    flags: 'i'
+  - regex: 'error\[E0463\]: can''t find crate for `[a-z]'
+    flags: 'i'
+error_messages:
+  - 'error: no such command: `make`'
+  - 'error: no such command: `expand`'
+  - 'error: no such subcommand: `make`'
+root_cause: |
+  On `windows-11-arm` runners, `shell: bash` resolves to `C:\Program Files\Git\bin\bash.EXE`,
+  which is an x86_64 binary running under WoW64 (Windows-on-Windows 64-bit) ARM64
+  emulation. The `actions/runner` binary on this platform is a **native ARM64** process.
+  When the native ARM64 runner spawns the x86_64 bash.EXE as a child process, an
+  intermittent failure in the WoW64 cross-architecture process launch causes the bash
+  process to start but never execute its script body. The step logs the command invocation
+  and environment dump, then exits 0 with zero script output — the script never ran.
+
+  Key characteristics:
+  - Failure is transient per-process-invocation: two consecutive bash steps in the same
+    job can have one succeed and one fail, ruling out image or runner misconfiguration.
+  - Zero-output steps take 0-3 seconds; successful steps take 2-7 seconds.
+  - Only occurs on `windows-11-arm`; `windows-latest` (amd64) is unaffected.
+  - The downstream step then fails with "no such command" or "not installed" errors because
+    the tool that was supposed to be installed by the bash step is missing.
+  - Reported across multiple independent Microsoft repositories
+    (microsoft/Windows-rust-driver-samples, microsoft/windows-drivers-rs), confirming
+    this is a platform-level runner bug, not a workflow configuration issue.
+
+  Root cause: intermittent x86_64 process execution failure under ARM64 WoW64 emulation
+  when launched from a native ARM64 parent process. No fix from the platform side as of
+  April 2026; actions/runner issue is open in partner-runner-images.
+fix: |
+  Option 1 (recommended): invoke bash from PowerShell as a workaround. Wrapping the bash
+  call in a pwsh step bypasses the native-arm64 → x86_64 WoW64 launch that triggers the
+  bug, because PowerShell on windows-11-arm is itself x86_64, so spawning x86_64 bash
+  from x86_64 pwsh does not cross the ARM64/x86_64 boundary:
+
+    - name: Run script via pwsh workaround
+      shell: pwsh
+      run: |
+        $result = & 'C:\Program Files\Git\bin\bash.EXE' -c "./your-script.sh"
+        if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
+
+  Option 2: use `shell: pwsh` for the entire step and rewrite the logic in PowerShell.
+
+  Option 3: add a retry wrapper that re-runs the composite action step if the output
+  is unexpectedly empty (e.g. check for absence of the installed binary before proceeding
+  and re-invoke if missing).
+
+  Option 4: avoid `windows-11-arm` in the runner matrix until the platform bug is fixed
+  upstream, or pin to `windows-latest` (amd64) for bash-heavy composite actions.
+fix_code:
+  - language: yaml
+    label: 'Invoke bash from pwsh to avoid the WoW64 ARM64 launch bug'
+    code: |
+      - name: Install tool (windows-11-arm workaround)
+        shell: pwsh
+        run: |
+          # Call x86_64 bash from x86_64 pwsh — avoids native-arm64 → x86_64 WoW64 issue
+          & 'C:\Program Files\Git\bin\bash.EXE' --noprofile --norc `
+            "${env:GITHUB_ACTION_PATH}/main.sh"
+          if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
+  - language: yaml
+    label: 'Exclude windows-11-arm from bash-heavy matrix jobs'
+    code: |
+      jobs:
+        build:
+          strategy:
+            matrix:
+              os: [windows-latest, ubuntu-latest, macos-latest]
+              # windows-11-arm excluded: shell: bash intermittent zero-output bug
+              # See: https://github.com/actions/partner-runner-images/issues/169
+prevention:
+  - 'Test composite actions on windows-11-arm at scale before relying on them in production CI.'
+  - 'Add post-step verification that checks for the installed binary; fail explicitly rather than silently continuing.'
+  - 'Monitor taiki-e/install-action release notes for the official workaround (pwsh retry wrapper) if using that action.'
+  - 'Prefer shell: pwsh over shell: bash for setup/install scripts in composite actions targeting windows-11-arm.'
+docs:
+  - url: 'https://github.com/actions/partner-runner-images/issues/169'
+    label: '[windows-11-arm] Composite action bash steps intermittently produce zero output and exit 0'
+  - url: 'https://github.com/taiki-e/install-action/issues/1562'
+    label: 'On windows-11-arm, sometimes does nothing, but succeeds'
+  - url: 'https://github.com/taiki-e/install-action/pull/1647'
+    label: 'Call main.sh from pwsh on Windows to work around windows-11-arm runner bug'

package/errors/triggers/triggers-069.yml

@@ -0,0 +1,100 @@
+id: triggers-069
+title: 'push tags: filter silently stops all branch-push triggers — branches: filter must be added separately to also run on branch commits'
+category: triggers
+severity: silent-failure
+tags:
+  - push
+  - tags-filter
+  - branches
+  - silent-failure
+  - trigger-missing
+  - filter-whitelist
+patterns:
+  - regex: 'on:\s*\n\s+push:\s*\n\s+tags:'
+    flags: 'i'
+error_messages: []
+root_cause: |
+  When a workflow specifies on: push: with only a tags: filter and no branches: filter,
+  ALL branch push events are silently excluded. The workflow fires exclusively on tag
+  pushes matching the tags: pattern.
+
+  This contradicts the common mental model that tags: adds an extra "also trigger on
+  these tags" condition on top of the default "trigger on all branch pushes" behavior.
+  In reality, any filter key under on: push: (branches:, tags:, branches-ignore:,
+  tags-ignore:, paths:) replaces the implicit "trigger on everything" default with a
+  whitelist. Specifying tags: without branches: means only tags match.
+
+  A workflow with:
+    on:
+      push:
+        tags:
+          - 'v*'
+
+  will never fire when code is pushed to main, feature branches, or any other branch.
+  If the team also needs CI on commits to main or pull request merges, a separate
+  branches: filter is required in the same on: push: block.
+
+  This is the inverse of the documented "branches: filter does not block tag pushes"
+  behavior (triggers-055). Both stem from the same whitelist-per-filter-key design.
+fix: |
+  Add an explicit branches: filter alongside tags: to restore branch-push triggering:
+
+    on:
+      push:
+        branches:
+          - main
+        tags:
+          - 'v*'
+
+  If only tag-based triggering is intended (e.g., a release workflow), the original
+  configuration is correct. Document the intent clearly so future maintainers do not
+  accidentally add branches: thinking CI was "broken".
+
+  To trigger on ALL branch pushes plus specific tags, omit branches: from on: push:
+  and add a separate on: push: tags: entry — but note that on: push: without filters
+  and on: push: tags: cannot coexist in the same block; split into two trigger blocks
+  using pull_request for branch coverage and push: tags: for tags.
+fix_code:
+  - language: yaml
+    label: 'Bug: tags: filter silently excludes all branch-push events'
+    code: |
+      on:
+        push:
+          tags:
+            - 'v*'
+      # Workflow NEVER runs on branch pushes — only fires when a v* tag is pushed
+  - language: yaml
+    label: 'Fix: add branches: filter to also run on branch commits'
+    code: |
+      on:
+        push:
+          branches:
+            - main
+            - 'release/**'
+          tags:
+            - 'v*'
+
+      jobs:
+        ci:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: make test
+  - language: yaml
+    label: 'Intentional tag-only release workflow (correct if branch CI is handled in a separate workflow)'
+    code: |
+      # release.yml — intentionally runs only on release tags
+      on:
+        push:
+          tags:
+            - 'v[0-9]+.[0-9]+.[0-9]+'
+prevention:
+  - 'Remember that any filter key under on: push: creates a whitelist — adding tags: without branches: stops all branch-push triggers silently'
+  - 'Keep release tag workflows in a dedicated file (release.yml) separate from branch-CI workflows (ci.yml) to avoid accidentally merging their trigger logic'
+  - 'After adding a tags: filter to an existing workflow, push a test commit to a branch and verify the workflow appears in the Actions tab'
+  - 'Use nektos/act or GitHub Actions VS Code extension to preview which events match a workflow trigger before merging'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#push'
+    label: 'GitHub Docs: push event filters'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore'
+    label: 'GitHub Docs: Workflow syntax — on.push filter keys'

package/errors/yaml-syntax/continue-on-error-inputs-composite-action-unexpected-value.yml

@@ -0,0 +1,110 @@
+id: yaml-syntax-070
+title: "continue-on-error expression using inputs.* silently resolves null at composite action call site \u2014 \"Unexpected value ''\""
+category: yaml-syntax
+severity: error
+tags:
+  - continue-on-error
+  - composite-actions
+  - inputs-context
+  - expression-scoping
+  - template-validation
+patterns:
+  - regex: 'Unexpected value\s+''''$'
+    flags: 'i'
+  - regex: 'error.*determining.*continue on error'
+    flags: 'i'
+  - regex: 'The template is not valid.*Unexpected value\s+'''
+    flags: 'i'
+error_messages:
+  - "Error: .github/workflows/test.yml (Line: N, Col: N): Unexpected value ''"
+  - 'Error: The step failed and an error occurred when attempting to determine whether to continue on error.'
+  - "Error: The template is not valid. .github/workflows/test.yml (Line: N, Col: N): Unexpected value ''"
+root_cause: |
+  When continue-on-error on a uses: step that calls a composite action contains an
+  expression referencing inputs.*, the expression is evaluated inside the composite
+  action context — not the calling workflow context. Inside the composite action,
+  inputs refers to the composite action''s own declared inputs, not the caller''s
+  workflow_dispatch inputs or other workflow-level inputs.
+
+  If the composite action does not declare that input, inputs.my_flag resolves to
+  null, which becomes an empty string in the expression context. The runner then
+  tries to parse the empty string as a boolean and emits:
+
+    Error: Unexpected value ''
+
+  followed by:
+
+    Error: The step failed and an error occurred when attempting to determine
+    whether to continue on error.
+
+  The workflow then halts at that step regardless of what the caller intended.
+
+  This context-crossing is unique to uses: steps (composite actions). For run:
+  steps in the same job, inputs.my_flag evaluates in the workflow context and
+  works correctly with continue-on-error.
+fix: |
+  Replace inputs.* with github.event.inputs.* in the continue-on-error expression
+  when calling composite actions from a workflow_dispatch event. github.event.inputs
+  is evaluated in the workflow/runner context before the composite action is entered,
+  so it resolves correctly.
+
+  Alternatively, capture the input as a job-level env or step output and reference
+  the env var or step output in the continue-on-error expression.
+fix_code:
+  - language: yaml
+    label: 'Bug: inputs.continue resolves to null inside composite action context'
+    code: |
+      on:
+        workflow_dispatch:
+          inputs:
+            continue:
+              type: boolean
+              default: false
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: my-org/fail-action@main
+              # inputs.continue resolves to null here — "Unexpected value ''"
+              continue-on-error: ${{ github.event_name == 'workflow_dispatch' && inputs.continue }}
+  - language: yaml
+    label: 'Fix: use github.event.inputs.* instead of inputs.* in continue-on-error on uses: steps'
+    code: |
+      on:
+        workflow_dispatch:
+          inputs:
+            continue:
+              type: boolean
+              default: false
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: my-org/fail-action@main
+              # github.event.inputs evaluates in workflow context, not composite context
+              continue-on-error: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.continue == 'true' }}
+  - language: yaml
+    label: 'Alternative fix: pre-evaluate the flag into an env var'
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          env:
+            SHOULD_CONTINUE: ${{ inputs.continue }}
+          steps:
+            - uses: my-org/fail-action@main
+              continue-on-error: ${{ env.SHOULD_CONTINUE == 'true' }}
+prevention:
+  - 'Never reference inputs.* in continue-on-error on a uses: step — use github.event.inputs.* for workflow_dispatch inputs or env.* for pre-evaluated values'
+  - 'Remember that expression contexts differ between run: steps (workflow context) and uses: composite action steps (composite context)'
+  - 'Test continue-on-error with expressions locally using nektos/act before merging to catch context-crossing issues'
+  - 'If a composite action needs conditional behavior, declare it as an explicit composite input and pass the value from the caller'
+docs:
+  - url: 'https://github.com/actions/runner/issues/2418'
+    label: 'GitHub runner#2418: continue-on-error with inputs variables in composite actions (bug, 12 reactions)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#context-availability'
+    label: 'GitHub Docs: Expression context availability'
+  - url: 'https://docs.github.com/en/actions/sharing-automations/creating-actions/creating-a-composite-action'
+    label: 'GitHub Docs: Creating a composite action'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@htekdev/actions-debugger",
-  "version": "1.0.114",
+  "version": "1.0.116",
   "description": "65+ real GitHub Actions errors, queryable by agents. CLI + MCP server + Copilot skills + error database.",
   "type": "module",
   "main": "./dist/index.js",