@htekdev/actions-debugger 1.0.123 → 1.0.125

package/errors/silent-failures/silent-failures-116.yml

@@ -0,0 +1,117 @@
+id: silent-failures-116
+title: 'actions/checkout sparse-checkout silently falls back to full REST API download when git < 2.28'
+category: silent-failures
+severity: silent-failure
+tags:
+  - checkout
+  - sparse-checkout
+  - git-version
+  - self-hosted
+  - rest-api-fallback
+  - silent
+  - git
+patterns:
+  - regex: 'Minimum Git version required for sparse checkout is 2\.28'
+    flags: 'i'
+  - regex: 'Failed to initialize CommandManager.*sparse'
+    flags: 'i'
+  - regex: 'Falling back to downloading using the GitHub REST API'
+    flags: 'i'
+error_messages:
+  - 'Minimum Git version required for sparse checkout is 2.28. Your git (/path/to/git) is 2.23'
+  - 'Falling back to downloading using the GitHub REST API'
+  - 'Warning: The git version installed on this runner is 2.x which is lower than the minimum required version 2.28 for sparse checkout'
+root_cause: |
+  actions/checkout supports `sparse-checkout` configuration, which requires git 2.28 or
+  later (because sparse-checkout with cone-mode patterns uses `git sparse-checkout init`,
+  introduced in that version).
+
+  When checkout attempts to initialise the git CommandManager and git is present on the
+  runner but too old to satisfy the sparse-checkout requirement, the action's
+  `getGitCommandManager` function throws an error. However, this error is caught in a
+  broad try/catch block:
+
+    } catch (err) {
+      // Git is required for LFS
+      if (settings.lfs) { throw err }
+      // otherwise: silently continue without git
+    }
+
+  Because `lfs` is not enabled, the error is swallowed without being logged to the
+  workflow output. Checkout falls back to downloading the repository as a ZIP archive
+  via the GitHub REST API and extracts it into the workspace.
+
+  The result is a **full clone** of the repository (subject to `fetch-depth`), not a
+  sparse checkout. All files are present in the workspace instead of only the requested
+  sparse paths. Workflows relying on sparse checkout to reduce disk usage or build time
+  proceed with the full repository content, potentially causing subtle downstream failures
+  (out-of-disk, dependency version mismatches, unexpected files in build artefacts) with
+  no indication that sparse-checkout was skipped.
+
+  This primarily affects **self-hosted runners** where a locally installed git binary is
+  older than 2.28 (e.g., git 2.17 shipped with Ubuntu 18.04, or git 2.23 on Amazon Linux
+  running in an older container). GitHub-hosted runners ship git 2.43+ and are not affected.
+
+  Reported in actions/checkout#2435 (May 2026).
+fix: |
+  **Step 1: Identify the failure.**
+  Add a step to print the git version before checkout:
+    - run: git --version
+
+  If the version is below 2.28, that is the root cause of the silent fallback.
+
+  **Step 2: Upgrade git on self-hosted runners.**
+  Install a modern git version (2.28+) on the runner. For Ubuntu:
+    sudo add-apt-repository ppa:git-core/ppa
+    sudo apt-get update && sudo apt-get install -y git
+
+  **Step 3: Until git is upgraded, disable sparse-checkout.**
+  Remove or guard the `sparse-checkout` input to avoid the silent fallback:
+    sparse-checkout: ''
+
+  **Alternative: require a minimum git version in the workflow.**
+  Fail fast with an explicit error rather than a silent fallback by checking the version
+  before the checkout step.
+fix_code:
+  - language: yaml
+    label: 'Add explicit git version gate before checkout with sparse-checkout'
+    code: |
+      - name: Verify git version supports sparse-checkout
+        run: |
+          GIT_VERSION=$(git --version | awk '{print $3}')
+          MIN_VERSION="2.28.0"
+          if [ "$(printf '%s\n' "$MIN_VERSION" "$GIT_VERSION" | sort -V | head -n1)" != "$MIN_VERSION" ]; then
+            echo "::error::git $GIT_VERSION is too old for sparse-checkout (requires >= 2.28)"
+            exit 1
+          fi
+
+      - uses: actions/checkout@v6
+        with:
+          sparse-checkout: |
+            src/
+            tests/
+  - language: yaml
+    label: 'Upgrade git on Ubuntu self-hosted runner before checkout'
+    code: |
+      - name: Ensure git >= 2.28 for sparse-checkout support
+        run: |
+          sudo add-apt-repository -y ppa:git-core/ppa
+          sudo apt-get update -q
+          sudo apt-get install -y git
+          git --version
+
+      - uses: actions/checkout@v6
+        with:
+          sparse-checkout: |
+            src/
+prevention:
+  - 'Always confirm the git version on self-hosted runners meets the minimum requirements for checkout features you use; add a preflight check step if runners may have older git installs'
+  - 'Pin to a specific version of actions/checkout and audit the changelog when upgrading — the sparse-checkout silent fallback has existed across multiple major versions'
+  - 'If disk usage is a concern and sparse-checkout is required, add a post-checkout assertion that only the expected sparse paths exist, which will catch the REST API fallback'
+docs:
+  - url: 'https://github.com/actions/checkout/issues/2435'
+    label: 'actions/checkout#2435 — Errors from initializing gitCommandManager are silently ignored'
+  - url: 'https://github.com/actions/checkout#usage'
+    label: 'actions/checkout README — sparse-checkout input and requirements'
+  - url: 'https://git-scm.com/docs/git-sparse-checkout'
+    label: 'Git documentation — git-sparse-checkout (requires git 2.25+, cone mode 2.26+)'

package/errors/silent-failures/silent-failures-117.yml

@@ -0,0 +1,137 @@
+id: silent-failures-117
+title: 'if: always() runs steps even when the workflow is manually cancelled — use success() || failure() to respect cancellation'
+category: silent-failures
+severity: silent-failure
+tags:
+  - if-condition
+  - always
+  - cancelled
+  - cleanup
+  - notification
+  - status-check
+  - silent-failure
+patterns:
+  - regex: 'if:\s*always\(\)'
+    flags: 'i'
+  - regex: 'if:\s*\$\{\{\s*always\(\)\s*\}\}'
+    flags: 'i'
+error_messages:
+  - '(no error emitted — steps run unexpectedly during workflow cancellation)'
+root_cause: |
+  Developers commonly add `if: always()` to steps or jobs that should run even when
+  a previous step fails — for example, uploading test reports after a failed test run,
+  or sending failure notifications.
+
+  The silent failure is that `always()` evaluates to `true` in ALL cases including
+  when the workflow is manually cancelled. When a user or a concurrency group cancellation
+  triggers, any step or job with `if: always()` still executes. This is often unintended:
+  the developer expected "run on failure" not "run even when someone cancels".
+
+  GitHub Actions documentation explicitly warns about this:
+    "Consider using if: !cancelled() if you want the step or job to continue
+     executing when the current run is cancelled. [...] Using always() is not
+     recommended as it causes a step to run when a workflow is cancelled, which
+     can result in unintended behavior."
+
+  Common scenarios where this causes problems:
+  - Test report upload step runs when a PR author cancels a run, unnecessarily consuming
+    runner minutes and potentially posting partial results to a PR check.
+  - Slack/PagerDuty notification fires for a manual cancellation, producing false alerts.
+  - Deploy rollback job runs during a cancellation of a non-deployment workflow, triggering
+    rollback unexpectedly.
+  - Cleanup job executes with only partial data because the workflow was cut short.
+
+  The correct alternative for "run when success OR failure, but NOT when cancelled" is:
+    if: success() || failure()
+  or equivalently:
+    if: ${{ !cancelled() }}
+
+  Source: Stack Overflow q/58858429 (415 upvotes, 327k views), GitHub Docs always() warning,
+  test-summary/action#51 community discussion (Jan 2025).
+fix: |
+  Replace `if: always()` with `if: success() || failure()` for steps and jobs that
+  should run on success or failure but NOT when the workflow is cancelled.
+
+  Use `if: always()` only when you explicitly want the step to run even during
+  cancellation — for example, an emergency teardown that must run regardless.
+
+  Three options depending on intent:
+
+  1. Run on success or failure (skip on cancel): `if: success() || failure()`
+  2. Run on any non-success outcome (skip on cancel): `if: failure()`
+  3. Run always including on cancel (current behaviour): `if: always()`
+
+  GitHub also documents `if: ${{ !cancelled() }}` as equivalent to option 1 in
+  most contexts.
+fix_code:
+  - language: yaml
+    label: 'Before: if: always() fires even on manual cancellation'
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - run: pytest --junitxml=results.xml
+
+            - name: Upload test results
+              if: always()          # fires even when the job is cancelled mid-run
+              uses: actions/upload-artifact@v4
+              with:
+                name: test-results
+                path: results.xml
+  - language: yaml
+    label: 'After: if: success() || failure() respects cancellation'
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - run: pytest --junitxml=results.xml
+
+            - name: Upload test results
+              if: success() || failure()   # runs on pass or fail; skips on cancel
+              uses: actions/upload-artifact@v4
+              with:
+                name: test-results
+                path: results.xml
+  - language: yaml
+    label: 'Notification job: skip Slack alert on cancellation'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - run: make build
+
+        notify:
+          needs: build
+          # success() || failure() fires on build success or failure, not on cancel
+          if: success() || failure()
+          runs-on: ubuntu-latest
+          steps:
+            - name: Notify Slack
+              run: |
+                echo "Build result: ${{ needs.build.result }}"
+                # Sends alert only on success or failure — not on manual cancel
+
+        # Only use always() when you MUST run on cancellation too:
+        emergency-cleanup:
+          needs: build
+          if: always()       # intentional: must clean up even if cancelled
+          runs-on: ubuntu-latest
+          timeout-minutes: 4 # stay under the 5-min forced-kill window
+          steps:
+            - run: ./cleanup.sh
+prevention:
+  - 'Default to `if: success() || failure()` for upload, notification, and cleanup steps — reserve `if: always()` only for teardown steps that truly must run on cancellation'
+  - 'Remember: `always()` is not "run when failure"; it is "run even when cancelled" — the distinction matters for notification jobs'
+  - 'GitHub docs recommend `if: ${{ !cancelled() }}` as an alternative to `if: success() || failure()` for the same effect'
+  - 'Combine `if: always()` with `timeout-minutes:` on any job that runs after cancellation; GitHub force-kills all jobs after 5 minutes of the cancellation signal'
+  - 'Run a quick cancellation test: manually cancel the workflow and verify whether notification steps fire unexpectedly'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#always'
+    label: 'GitHub Docs: always() status check function — cancellation warning'
+  - url: 'https://stackoverflow.com/questions/58858429/how-to-run-a-github-actions-step-even-if-the-previous-step-fails-while-still-failing-the-job'
+    label: 'Stack Overflow 58858429: Run step on failure while still failing the job (415 votes)'
+  - url: 'https://github.com/test-summary/action/issues/51'
+    label: 'test-summary/action#51: Use success() || failure() instead of always() to prevent running on cancel'

package/errors/silent-failures/silent-failures-118.yml

@@ -0,0 +1,156 @@
+id: silent-failures-118
+title: 'Reusable workflow jobs.<name>.result is always empty string in on.workflow_call.outputs value'
+category: silent-failures
+severity: silent-failure
+tags:
+  - reusable-workflow
+  - workflow_call
+  - outputs
+  - jobs-result
+  - empty-string
+  - silent-failure
+  - job-outcome
+patterns:
+  - regex: 'value:\s*\$\{\{\s*jobs\.[a-zA-Z0-9_-]+\.result\s*\}\}'
+    flags: 'i'
+  - regex: 'needs\.[a-zA-Z0-9_-]+\.outputs\.[a-zA-Z0-9_-]+.*result'
+    flags: 'i'
+error_messages:
+  - '(no error emitted — needs.<job>.outputs.<name> resolves to empty string in the caller)'
+root_cause: |
+  GitHub Actions documentation states that the `jobs` context is available in
+  reusable workflows and includes `jobs.<job_id>.result` — the job conclusion value
+  ("success", "failure", "cancelled", or "skipped"). Developers use this to expose job
+  outcomes to calling workflows via `on.workflow_call.outputs`.
+
+  However, `jobs.<job_id>.result` does NOT work when used in the `value:` expression of
+  `on.workflow_call.outputs`. It always resolves to an empty string ("") in the caller's
+  `needs.<called_job>.outputs.<name>`.
+
+  This is distinct from the two-level output declaration issue (sf-060) where developers
+  forget to declare outputs at the workflow_call level. Here the developer correctly
+  declares both levels, but uses `jobs.<name>.result` (the job outcome) instead of
+  `jobs.<name>.outputs.<step-output>` (a custom output). The `.result` property is
+  simply not available via this mechanism.
+
+  Workarounds discovered by the community:
+  1. Explicitly capture the outcome as a step output and then chain it through job outputs:
+       steps:
+         - id: capture
+           run: echo "result=${{ job.status }}" >> "$GITHUB_OUTPUT"
+       outputs:
+         result: ${{ steps.capture.outputs.result }}
+  2. Use `fromJSON(toJSON(jobs.build)).result` — this works because it forces the
+     expression evaluator to serialise and deserialise the jobs context object, which
+     happens to populate the result at evaluation time. This is an accidental workaround
+     and not guaranteed to remain stable.
+
+  The root cause is that the `jobs.<job_id>.result` property in the workflow_call outputs
+  `value:` expression is evaluated before job conclusions are fully committed to the
+  expression context, unlike `jobs.<job_id>.outputs.<name>` which goes through a different
+  code path.
+
+  Source: actions/runner#2495 (open since 2023, multiple upvotes),
+  actions/runner#3087 (Cannot access jobs.<id>.result from on.workflow_call.outputs..value).
+fix: |
+  Do NOT use `value: ${{ jobs.<name>.result }}` in on.workflow_call.outputs — it will
+  always be empty in the caller.
+
+  **Option 1 (recommended): Capture outcome via a step output.**
+  Add a final step that writes `job.status` to GITHUB_OUTPUT, then chain it up:
+    step output → job output → workflow_call output
+
+  **Option 2: Use fromJSON(toJSON(jobs.<name>)).result workaround.**
+  The fromJSON/toJSON wrapper forces the jobs context to be serialised at evaluation
+  time, which makes .result available. This is a workaround — prefer option 1.
+
+  **Option 3: Control caller behavior via job success/failure instead of reading result.**
+  If you only need to run downstream caller jobs conditionally based on the reusable
+  workflow succeeding or failing, use `if: needs.<job>.result == 'success'` — the
+  `needs.<job>.result` in the CALLER is always correct and does NOT need to go through
+  workflow_call outputs.
+fix_code:
+  - language: yaml
+    label: 'Broken: value: ${{ jobs.build.result }} is always empty in caller'
+    code: |
+      # .github/workflows/reusable.yml — BROKEN pattern
+      on:
+        workflow_call:
+          outputs:
+            build-result:
+              description: 'Job outcome of the build job'
+              value: ${{ jobs.build.result }}   # always empty string in caller
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - run: make build
+  - language: yaml
+    label: 'Fixed: capture outcome via step output and chain it through job outputs'
+    code: |
+      # .github/workflows/reusable.yml — CORRECT pattern
+      on:
+        workflow_call:
+          outputs:
+            build-result:
+              description: 'Job outcome of the build job'
+              value: ${{ jobs.build.outputs.result }}   # works correctly
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          outputs:
+            result: ${{ steps.capture.outputs.result }}
+          steps:
+            - run: make build
+
+            - id: capture
+              if: always()
+              shell: bash
+              run: echo "result=${{ job.status }}" >> "$GITHUB_OUTPUT"
+  - language: yaml
+    label: 'Alternative workaround: fromJSON(toJSON(jobs.build)).result (fragile, prefer option 1)'
+    code: |
+      # .github/workflows/reusable.yml — accidental workaround (not recommended)
+      on:
+        workflow_call:
+          outputs:
+            build-result:
+              value: ${{ fromJSON(toJSON(jobs.build)).result }}
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - run: make build
+  - language: yaml
+    label: 'Caller: reading needs.<job>.result directly works and does NOT need workflow_call outputs'
+    code: |
+      # .github/workflows/caller.yml
+      # needs.<job>.result in the CALLER is always correct — no need to pass it through outputs
+      jobs:
+        call-build:
+          uses: ./.github/workflows/reusable.yml
+
+        deploy:
+          needs: call-build
+          # This works correctly — reads the reusable workflow conclusion directly
+          if: needs.call-build.result == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - run: ./deploy.sh
+prevention:
+  - 'Never use `value: ${{ jobs.<name>.result }}` in workflow_call outputs — capture it as a step output first'
+  - 'If you only need to gate downstream caller jobs on reusable workflow success/failure, use `needs.<job>.result` in the caller directly — it works without going through workflow_call outputs'
+  - 'Test output values by printing them in the caller with `run: echo "${{ needs.<job>.outputs.<name> }}"` before relying on them in logic'
+  - 'The `fromJSON(toJSON(...)).result` workaround works today but is fragile — prefer the step-output capture pattern'
+docs:
+  - url: 'https://github.com/actions/runner/issues/2495'
+    label: 'actions/runner#2495: Reusable workflow does not output individual job result'
+  - url: 'https://github.com/actions/runner/issues/3087'
+    label: 'actions/runner#3087: Cannot access jobs.<id>.result from on.workflow_call.outputs..value'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_calloutputs'
+    label: 'GitHub Docs: on.workflow_call.outputs syntax reference'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#jobs-context'
+    label: 'GitHub Docs: jobs context (available only in reusable workflows)'

package/errors/yaml-syntax/yaml-syntax-075.yml

@@ -0,0 +1,128 @@
+id: yaml-syntax-075
+title: 'environment: shorthand string format silently rejects needs.* and jobs.* contexts — use environment.name form'
+category: yaml-syntax
+severity: error
+tags:
+  - environment
+  - dynamic-environment
+  - needs-context
+  - expression
+  - shorthand
+  - template-validation
+patterns:
+  - regex: 'Unrecognized named-value.*needs.*environment'
+    flags: 'i'
+  - regex: "Unrecognized named-value: 'needs'.*position.*expression.*needs\\."
+    flags: 'i'
+  - regex: 'TemplateValidationException.*Unrecognized named-value.*needs'
+    flags: 'i'
+error_messages:
+  - "The workflow is not valid. .github/workflows/deploy.yml (Line: 15, Col: 18): Unrecognized named-value: 'needs'. Located at position 1 within expression: needs.set_environment.outputs.my_env"
+  - "Unrecognized named-value: 'needs'. Located at position 1 within expression: needs.X.outputs.env"
+root_cause: |
+  The GitHub Actions workflow parser supports two forms for specifying a job environment:
+
+  1. Shorthand string: `environment: production` or `environment: ${{ some.expression }}`
+  2. Explicit mapping: `environment:\n  name: ${{ expression }}\n  url: ${{ expression }}`
+
+  The shorthand string form (`environment: ${{ ... }}`) supports only a limited expression
+  context and does NOT support the `needs.*` or `jobs.*` contexts, even when the job
+  has `needs:` declared. Attempting to use `needs.X.outputs.Y` inside the shorthand
+  produces a TemplateValidationException at workflow parse time:
+
+    "Unrecognized named-value: 'needs'. Located at position 1 within expression: needs.X.outputs.Y"
+
+  The explicit mapping form (`environment:\n  name: ${{ ... }}`) DOES support the `needs.*`
+  context fully — this is the documented way to set a dynamic environment name or URL.
+
+  This trips up developers who:
+  - Copy the shorthand form from documentation examples and add an expression.
+  - Want to choose between staging/production environments based on the branch output
+    of an earlier job.
+  - Try to set a dynamic environment URL using `needs.deploy.outputs.url`.
+
+  The error appears only at workflow validation time (not at job runtime), which means
+  the entire workflow is rejected before any jobs run.
+fix: |
+  Use the explicit `environment:` mapping format with `name:` and optionally `url:` sub-keys
+  instead of the shorthand string with a `${{ }}` expression.
+
+  The shorthand `environment: ${{ expression }}` is only for literal strings or simple
+  expressions without `needs.*` / `jobs.*`. Once you need cross-job outputs, switch to
+  the explicit form.
+fix_code:
+  - language: yaml
+    label: 'Broken — shorthand with needs.* context causes TemplateValidationException'
+    code: |
+      jobs:
+        determine-env:
+          runs-on: ubuntu-latest
+          outputs:
+            target: ${{ steps.pick.outputs.env }}
+          steps:
+            - id: pick
+              run: echo "env=production" >> $GITHUB_OUTPUT
+
+        deploy:
+          needs: determine-env
+          runs-on: ubuntu-latest
+          # ❌ BROKEN: shorthand does not support needs.* context
+          environment: ${{ needs.determine-env.outputs.target }}
+          steps:
+            - run: echo "deploying"
+
+  - language: yaml
+    label: 'Fixed — explicit environment.name form supports needs.* context'
+    code: |
+      jobs:
+        determine-env:
+          runs-on: ubuntu-latest
+          outputs:
+            target: ${{ steps.pick.outputs.env }}
+          steps:
+            - id: pick
+              run: |
+                if [[ "${{ github.ref_name }}" == "main" ]]; then
+                  echo "env=production" >> $GITHUB_OUTPUT
+                else
+                  echo "env=staging" >> $GITHUB_OUTPUT
+                fi
+
+        deploy:
+          needs: determine-env
+          runs-on: ubuntu-latest
+          # ✅ FIXED: explicit name: sub-key supports needs.* context
+          environment:
+            name: ${{ needs.determine-env.outputs.target }}
+            url: ${{ needs.deploy.outputs.deploy_url }}
+          steps:
+            - run: echo "deploying to ${{ needs.determine-env.outputs.target }}"
+
+  - language: yaml
+    label: 'Dynamic environment from workflow_dispatch input — correct form'
+    code: |
+      on:
+        workflow_dispatch:
+          inputs:
+            environment:
+              required: true
+              type: environment
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          # ✅ Use explicit name: when referencing inputs.* or needs.* contexts
+          environment:
+            name: ${{ inputs.environment }}
+          steps:
+            - run: echo "deploying to ${{ inputs.environment }}"
+prevention:
+  - 'Always use the `environment:\n  name: ${{ }}` form (never the shorthand string) when the environment name is dynamic or derived from another job.'
+  - 'Remember: `environment: ${{ expression }}` is valid syntax but only for literal strings — it silently ignores `needs.*` context at parse time, producing a hard error.'
+  - 'Lint with actionlint (v1.7.0+) which detects this pattern before pushing.'
+docs:
+  - url: 'https://github.com/actions/runner/issues/998'
+    label: 'actions/runner#998 — Setting job environment dynamically fails with needs context in shorthand form'
+  - url: 'https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment'
+    label: 'GitHub Docs — jobs.<job_id>.environment syntax reference'
+  - url: 'https://stackoverflow.com/questions/65826284/use-dynamic-input-value-for-environment-in-github-actions-workflow-job'
+    label: 'Stack Overflow — Dynamic environment in GitHub Actions workflow job (many upvotes)'

package/errors/yaml-syntax/yaml-syntax-076.yml

@@ -0,0 +1,107 @@
+id: yaml-syntax-076
+title: 'actionlint <=1.7.7 rejects valid `entrypoint` and `command` keys on service containers — schema lag after April 2026 GitHub changelog'
+category: yaml-syntax
+severity: error
+tags:
+  - actionlint
+  - service-container
+  - entrypoint
+  - command
+  - schema-lag
+  - linting
+  - CI-check
+patterns:
+  - regex: 'unexpected key "entrypoint" for "services" section'
+    flags: 'i'
+  - regex: 'unexpected key "command" for "services" section'
+    flags: 'i'
+  - regex: 'unexpected key "(?:entrypoint|command)" for "services" section\. expected one of "credentials", "env", "image", "options", "ports", "volumes"'
+    flags: 'i'
+error_messages:
+  - '.github/workflows/test.yaml:9:9: unexpected key "entrypoint" for "services" section. expected one of "credentials", "env", "image", "options", "ports", "volumes" [syntax-check]'
+  - '.github/workflows/test.yaml:10:9: unexpected key "command" for "services" section. expected one of "credentials", "env", "image", "options", "ports", "volumes" [syntax-check]'
+root_cause: |
+  GitHub Actions added support for `entrypoint` and `command` keys on service container
+  definitions on April 2, 2026 (GitHub Actions: Early April 2026 updates changelog). These
+  new keys allow overriding the service container's default entrypoint and command directly from
+  workflow YAML, matching Docker Compose semantics:
+
+  ```yaml
+  services:
+    redis:
+      image: redis
+      entrypoint: redis-server
+      command: --save 60 1 --loglevel warning
+  ```
+
+  actionlint versions <=1.7.7 validate service container keys against a hardcoded schema that
+  only permits `credentials`, `env`, `image`, `options`, `ports`, and `volumes`. When a workflow
+  uses the new `entrypoint` or `command` keys, actionlint reports them as unknown properties with
+  a `[syntax-check]` error.
+
+  This causes CI pipelines that run actionlint as a lint check to fail even though the workflow
+  is perfectly valid on GitHub.com. The fix was merged into actionlint on April 19, 2026 and
+  released in v1.7.8.
+
+  This is a schema-lag pattern: a new GitHub Actions feature was released before the static
+  analysis tool's schema was updated to recognize it, causing a false-positive lint failure.
+fix: |
+  **Primary fix: Upgrade actionlint to >=1.7.8.**
+  The fix was merged April 19, 2026 (rhysd/actionlint#644). Update your CI pipeline to use
+  actionlint >=1.7.8:
+
+  ```yaml
+  - name: Run actionlint
+    uses: raven-actions/actionlint@v2
+    with:
+      version: latest  # or pin to 1.7.8+
+  ```
+
+  **Temporary workaround (if upgrading is not immediately possible):** Add an inline ignore
+  comment to suppress the false-positive while on the older actionlint version:
+
+  ```yaml
+  services:
+    redis:
+      image: redis
+      entrypoint: redis-server  # actionlint:ignore
+      command: --save 60 1      # actionlint:ignore
+  ```
+fix_code:
+  - language: yaml
+    label: 'Upgrade actionlint in CI to >=1.7.8 to recognize entrypoint/command service keys'
+    code: |
+      - name: Run actionlint
+        uses: raven-actions/actionlint@v2
+        with:
+          version: 1.7.8  # Minimum version that supports entrypoint/command on service containers
+  - language: yaml
+    label: 'Valid service container workflow using new entrypoint/command keys (GitHub Actions only)'
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          services:
+            redis:
+              image: redis:7
+              # These keys are valid on GitHub Actions (GA April 2, 2026)
+              # but require actionlint >=1.7.8 for linting to pass
+              entrypoint: redis-server
+              command: --save 60 1 --loglevel warning
+              ports:
+                - 6379:6379
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run tests
+              run: npm test
+prevention:
+  - 'Pin actionlint to a specific version in CI and include it in your Dependabot or Renovate configuration so schema updates are picked up promptly when new GitHub Actions features are released.'
+  - 'When a new GitHub Actions feature ships, check the actionlint changelog (https://github.com/rhysd/actionlint/releases) for schema support before using the feature in linted workflows.'
+  - 'Use `# actionlint:ignore` comment as a short-term workaround for valid-but-unknown-to-linter keys while waiting for the schema update.'
+docs:
+  - url: 'https://github.com/rhysd/actionlint/issues/644'
+    label: 'rhysd/actionlint#644 — Add support for entrypoint and command for service containers (fixed in v1.7.8)'
+  - url: 'https://github.blog/changelog/2026-04-02-github-actions-early-april-2026-updates/'
+    label: 'GitHub Changelog — April 2026 updates: entrypoint and command overrides for service containers'
+  - url: 'https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservicesservice_identrypoint'
+    label: 'GitHub Docs — Workflow syntax: jobs.<job_id>.services.<service_id>.entrypoint'

package/package.json

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