@htekdev/actions-debugger 1.0.117 → 1.0.119

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

@@ -0,0 +1,107 @@
+id: silent-failures-111
+title: '`helm list` shows all release states by default in Helm 4 — scripts silently return unexpected releases'
+category: silent-failures
+severity: silent-failure
+tags:
+  - helm
+  - helm-4
+  - ubuntu-26
+  - tool-upgrade
+  - output-change
+  - deploy-check
+patterns:
+  - regex: 'helm list'
+    flags: 'i'
+error_messages:
+  - '# No error message — helm list exits 0 but returns FAILED/SUPERSEDED/UNINSTALLED releases alongside DEPLOYED ones'
+root_cause: |
+  In Helm 3, `helm list` (without flags) only returned releases in the DEPLOYED
+  state. To see releases in all states, you had to pass `-a`/`--all`.
+
+  In Helm 4 (installed on ubuntu-26.04), `helm list` returns releases of ALL
+  states by default: DEPLOYED, FAILED, SUPERSEDED, UNINSTALLED, PENDING_INSTALL,
+  PENDING_UPGRADE, PENDING_ROLLBACK. The `-a`/`--all` flag was temporarily removed
+  (helm/helm#31784) and restored as a deprecated no-op in Helm 4.1.1+.
+
+  This causes silent failures in two common patterns:
+
+  1. **Existence check**: `helm list --filter my-release | grep my-release` returns
+     a match even if the release is in a FAILED state, causing a subsequent
+     `helm upgrade` to proceed when `helm install` should have been used instead
+     (or vice versa).
+
+  2. **Release count**: Scripts that count `helm list | wc -l` to assert a number
+     of deployed releases now count more releases than expected.
+
+  3. **CI deploy gate**: Pipelines that run `helm list` to verify a deployment
+     succeeded will see FAILED releases included in output and may incorrectly
+     conclude the deployment is present/healthy.
+
+  No error is thrown — `helm list` exits 0 in all cases. The bug is in the
+  consuming script's assumption about Helm 3 behavior.
+fix: |
+  Filter `helm list` output explicitly by state using the `--deployed` flag
+  or the `--filter`+`--output json` approach to check actual release status.
+
+  In Helm 4, use `helm status <release>` to get the definitive state of a
+  specific release rather than parsing `helm list` output.
+fix_code:
+  - language: yaml
+    label: 'Use --deployed flag to replicate Helm 3 default behavior'
+    code: |
+      - name: Check if release is deployed
+        run: |
+          # Helm 4 on ubuntu-26.04: helm list shows ALL states by default.
+          # Use --deployed to replicate Helm 3 default behavior:
+          DEPLOYED=$(helm list --deployed --filter "^my-release$" --short)
+          if [ -n "$DEPLOYED" ]; then
+            echo "Release is deployed — running upgrade"
+            helm upgrade my-release ./chart
+          else
+            echo "No deployed release found — running install"
+            helm install my-release ./chart
+          fi
+
+  - language: yaml
+    label: 'Use helm status for definitive state check'
+    code: |
+      - name: Check release status
+        run: |
+          # helm status exits non-zero if the release does not exist.
+          # Use --output json to get machine-parseable state:
+          STATUS=$(helm status my-release --output json 2>/dev/null | jq -r '.info.status' || echo "not-found")
+          echo "Release status: $STATUS"
+          if [ "$STATUS" = "deployed" ]; then
+            echo "Healthy — proceeding"
+          elif [ "$STATUS" = "failed" ]; then
+            echo "Previous install failed — rolling back before upgrade"
+            helm rollback my-release 0  # Roll back to last successful
+          else
+            echo "Installing fresh"
+            helm install my-release ./chart
+          fi
+
+  - language: yaml
+    label: 'Use helm list --output json for precise state parsing'
+    code: |
+      - name: List only deployed releases
+        run: |
+          # Explicitly request only DEPLOYED state, output JSON for safe parsing:
+          helm list --deployed --output json | jq '.[] | .name + " (" + .status + ")"'
+          # Do NOT rely on: helm list | grep release-name
+          # In Helm 4, this matches FAILED/SUPERSEDED releases too.
+prevention:
+  - "Never use `helm list | grep <release>` as a deployment check — it matches any release state in Helm 4."
+  - "Use `helm list --deployed` or `helm status <release>` for definitive deployed-state checks."
+  - "When migrating to ubuntu-26.04, audit all scripts that parse `helm list` output."
+  - "Add `--output json` to `helm list` calls and parse `status` field explicitly rather than relying on line-presence checks."
+  - "Pin Helm 3 with `azure/setup-helm` if your scripts are not yet Helm 4 compatible."
+docs:
+  - url: 'https://github.com/helm/helm/issues/31784'
+    label: 'helm/helm#31784 — Breaking change to helm list CLI command in v4'
+  - url: 'https://helm.sh/docs/topics/v4_migration/'
+    label: 'Helm v4 Migration Guide'
+  - url: 'https://helm.sh/docs/helm/helm_list/'
+    label: 'helm list command reference'
+  - url: 'https://github.com/actions/runner-images/commit/9e3319d6b4acc306925295853d0ff41ddd5c40f0'
+    label: 'runner-images commit: ubuntu-26.04 installs Helm 4'

package/errors/triggers/pull-request-labeled-fires-all-labels-no-name-filter.yml

@@ -0,0 +1,110 @@
+id: triggers-070
+title: '`on: pull_request: types: [labeled]` fires for every label applied to a PR —
+  no trigger-level label-name filter exists; must use `if:` condition'
+category: triggers
+severity: silent-failure
+tags:
+  - pull_request
+  - labeled
+  - label
+  - types
+  - label-name-filter
+  - deployment-gate
+patterns:
+  - regex: 'types:\s*[\[\n].*labeled'
+    flags: 'si'
+error_messages:
+  - "No error — workflow runs for every label applied to the PR, including unrelated labels"
+  - "No error — workflow run count is higher than expected; runs appear for all label events"
+root_cause: |
+  When `types: [labeled]` is added to a `pull_request` trigger, the workflow fires for
+  EVERY label applied to the pull request — not only a specific label. There is no
+  trigger-level filter for label names. GitHub Actions does not support syntax like
+  `types: [labeled: 'deploy-preview']` or `label: 'X'` at the trigger level.
+
+  Teams building label-gated workflows (deploy-preview, run-integration-tests,
+  approved-for-staging, force-rebuild) are surprised to find the workflow fires for
+  entirely unrelated labels ('bug', 'enhancement', 'wontfix', 'good first issue').
+  The result is:
+  - Excessive workflow runs that show up in the Actions tab for every label event
+  - Wasted CI minutes for runs that skip all meaningful steps
+  - Unexpected side effects if the workflow performs mutations (deploy, comment, notify)
+    that should only happen for the specific label
+
+  This is distinct from the related issue triggers-030 ("labeled NOT in default types"):
+  - triggers-030: workflow NEVER fires because labeled is missing from default types
+  - triggers-070: workflow fires TOO OFTEN because ALL label events trigger it
+
+  The behavior is documented: `types: [labeled]` is a webhook activity type filter,
+  not a payload content filter. Payload-level filtering (label name, PR author, etc.)
+  must be done via `if:` conditions on jobs or steps.
+fix: |
+  Add a job-level `if:` condition filtering on `github.event.label.name`. This is the
+  only mechanism — no trigger-level label-name filtering exists.
+
+  Key context properties for label-based filtering:
+  - `github.event.action` — 'labeled' or 'unlabeled'
+  - `github.event.label.name` — the label JUST applied (only set for labeled/unlabeled events)
+  - `github.event.pull_request.labels.*.name` — ALL current labels on the PR (useful for
+    opened/synchronize/reopened events where a label may already be present)
+fix_code:
+  - language: yaml
+    label: 'WRONG — fires for every label including unrelated ones'
+    code: |
+      on:
+        pull_request:
+          types: [labeled]
+
+      jobs:
+        deploy-preview:
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying preview..."
+            # Runs for EVERY label: 'bug', 'wontfix', 'enhancement', 'deploy-preview', etc.
+  - language: yaml
+    label: 'RIGHT — filter by specific label name with job-level if:'
+    code: |
+      on:
+        pull_request:
+          types: [labeled]
+
+      jobs:
+        deploy-preview:
+          if: github.event.label.name == 'deploy-preview'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying preview for PR #${{ github.event.pull_request.number }}"
+  - language: yaml
+    label: 'RIGHT — label gate that works for both labeled events AND already-labeled PRs'
+    code: |
+      on:
+        pull_request:
+          types:
+            - opened
+            - synchronize
+            - reopened
+            - labeled       # fires when any label is applied; filter below by name
+
+      jobs:
+        deploy-preview:
+          if: |
+            (github.event.action == 'labeled' && github.event.label.name == 'deploy-preview') ||
+            (github.event.action != 'labeled' && contains(github.event.pull_request.labels.*.name, 'deploy-preview'))
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying preview..."
+prevention:
+  - "Always pair `types: [labeled]` with `if: github.event.label.name == 'your-label'` at the job
+    level to gate on the specific label."
+  - 'Document which label triggers which workflow in a comment near the trigger definition.'
+  - 'Test label-gated workflows by applying both the expected label AND an unrelated label to verify
+    the `if:` filter correctly skips unintended runs.'
+  - 'Consider using only `types: [labeled]` (not opened/sync/reopened) if the workflow should only
+    run when the label is freshly applied, not on every code push to already-labeled PRs.'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request'
+    label: 'GitHub Docs: pull_request event — labeled activity type'
+  - url: 'https://docs.github.com/en/webhooks/webhook-events-and-payloads#pull_request'
+    label: 'GitHub Webhook Docs: pull_request payload (label field)'
+  - url: 'https://stackoverflow.com/questions/62325286/run-github-actions-when-pull-requests-have-a-specific-label'
+    label: 'Stack Overflow: Run GitHub Actions when pull requests have a specific label (43 votes)'

package/errors/yaml-syntax/duplicate-step-id-within-job-scope-validation-error.yml

@@ -0,0 +1,130 @@
+id: yaml-syntax-071
+title: 'Duplicate `id:` values within the same job or composite action cause instant
+  workflow validation failure'
+category: yaml-syntax
+severity: error
+tags:
+  - step-id
+  - duplicate
+  - validation
+  - composite-action
+  - copy-paste
+patterns:
+  - regex: 'The identifier .* may not be used more than once within the same scope'
+    flags: 'i'
+  - regex: 'TemplateValidationException.*may not be used more than once'
+    flags: 'i'
+error_messages:
+  - "The workflow is not valid. .github/workflows/ci.yml (Line: N, Col: N): The identifier 'checkout'
+    may not be used more than once within the same scope."
+  - "The identifier 'meta' may not be used more than once within the same scope."
+  - "GitHub.DistributedTask.ObjectTemplating.TemplateValidationException: The template is not valid."
+root_cause: |
+  Step IDs (`id:`) must be unique within a single job or composite action. If two or more
+  steps within the same scope share the same `id:` value, GitHub Actions rejects the entire
+  workflow before any step runs, throwing a `TemplateValidationException`.
+
+  Step IDs form the keys of the `steps` context object. Duplicate keys would make
+  `${{ steps.checkout.outputs.ref }}` ambiguous — the platform rejects this ambiguity at
+  parse time rather than silently choosing one arbitrarily at runtime.
+
+  The most common root cause is copy-pasting steps within a job — particularly repeating
+  `actions/checkout`, `docker/metadata-action`, or `actions/setup-node` blocks — without
+  updating or removing the `id:` field on the duplicate. Composite action authors also
+  hit this when a second action step is added without checking existing IDs.
+
+  The error message reports only the SECOND occurrence's line and column, not both —
+  making it harder to locate the original conflicting step in long step lists.
+  (Tracked as actions/runner#3121 as an open bug requesting improved error reporting.)
+fix: |
+  Ensure every step that declares an `id:` uses a unique value within its job or composite
+  action scope. Steps that are not referenced by later steps can omit `id:` entirely —
+  only steps whose outputs are used in expressions (`${{ steps.X.outputs.Y }}`) need an ID.
+fix_code:
+  - language: yaml
+    label: 'WRONG — duplicate id: "meta" causes TemplateValidationException'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Extract metadata for Docker Hub
+              id: meta                          # first declaration
+              uses: docker/metadata-action@v5
+              with:
+                images: myorg/myapp
+
+            - name: Extract metadata for GHCR
+              id: meta                          # DUPLICATE — workflow rejected
+              uses: docker/metadata-action@v5
+              with:
+                images: ghcr.io/myorg/myapp
+
+            - uses: docker/build-push-action@v6
+              with:
+                tags: ${{ steps.meta.outputs.tags }}
+  - language: yaml
+    label: 'RIGHT — unique IDs for each step'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Extract metadata for Docker Hub
+              id: meta-dockerhub
+              uses: docker/metadata-action@v5
+              with:
+                images: myorg/myapp
+
+            - name: Extract metadata for GHCR
+              id: meta-ghcr
+              uses: docker/metadata-action@v5
+              with:
+                images: ghcr.io/myorg/myapp
+
+            - name: Build and push to Docker Hub
+              uses: docker/build-push-action@v6
+              with:
+                tags: ${{ steps.meta-dockerhub.outputs.tags }}
+                labels: ${{ steps.meta-dockerhub.outputs.labels }}
+
+            - name: Build and push to GHCR
+              uses: docker/build-push-action@v6
+              with:
+                tags: ${{ steps.meta-ghcr.outputs.tags }}
+                labels: ${{ steps.meta-ghcr.outputs.labels }}
+  - language: yaml
+    label: 'RIGHT — omit id: on steps whose outputs are never referenced'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              # No id: needed — outputs not referenced by other steps
+
+            - uses: actions/setup-node@v4
+              with:
+                node-version: '20'
+              # No id: needed — only referenced outputs need a step id
+
+            - id: version
+              run: echo "version=$(node -p "require('./package.json').version")" >> $GITHUB_OUTPUT
+
+            - run: echo "Building version ${{ steps.version.outputs.version }}"
+prevention:
+  - 'When copy-pasting steps within a job, immediately update or remove the `id:` field on
+    the duplicate to avoid the conflict.'
+  - 'Use actionlint or a YAML linter locally before pushing — both catch duplicate step IDs
+    and report the error with line numbers for both occurrences.'
+  - 'Only assign `id:` to steps whose outputs are referenced in expressions elsewhere in the
+    job; leave unreferenced steps without `id:`.'
+  - 'Apply the same uniqueness rule to composite actions — step IDs within a composite action
+    must also be unique within the action file.'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid'
+    label: 'GitHub Docs: jobs.<job_id>.steps[*].id'
+  - url: 'https://github.com/actions/runner/issues/3121'
+    label: 'actions/runner#3121 — Request to improve duplicate step ID error message (Jan 2024)'
+  - url: 'https://ghlint.twisterrob.net/issues/default/DuplicateStepId/'
+    label: 'GH-Lint: DuplicateStepId rule documentation'

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

@@ -0,0 +1,93 @@
+id: yaml-syntax-072
+title: 'concurrency queue: max rejected as "Unknown Property" by act and actionlint (May 2026 schema lag)'
+category: yaml-syntax
+severity: error
+tags:
+  - concurrency
+  - queue
+  - act
+  - actionlint
+  - schema-validation
+  - local-ci
+  - queue-max
+patterns:
+  - regex: 'Unknown Property queue'
+    flags: 'i'
+  - regex: 'Failed to match concurrency-mapping.*Unknown Property queue'
+    flags: 'is'
+  - regex: 'concurrency.*queue.*unknown|queue.*max.*schema.*invalid'
+    flags: 'i'
+  - regex: 'actionlint.*"queue".*unknown key'
+    flags: 'i'
+error_messages:
+  - "Line: 4 Column 3: Unknown Property queue"
+  - "Failed to match concurrency-mapping: Line: 6 Column 3: Unknown Property queue"
+  - 'Actions YAML Schema Validation Error detected: Unknown Property queue'
+  - 'unknown key "queue" for "concurrency"'
+root_cause: |
+  GitHub added the `queue` field to the concurrency block in May 2026 (Changelog:
+  "GitHub Actions concurrency groups now allow larger queues"). The new field accepts
+  `single` (default — one pending run) or `max` (up to 100 queued runs).
+
+  Local workflow tooling has not been updated to recognize this field:
+
+  - **nektos/act ≤0.2.88** — `pkg/schema/workflow_schema.json` defines `concurrency-mapping`
+    with only `group` and `cancel-in-progress`. Any workflow using `queue: max` or
+    `queue: single` fails immediately at schema validation, before any step runs.
+
+  - **rhysd/actionlint ≤1.7.8** — the actionlint parser similarly rejects `queue` as an
+    unknown concurrency key, blocking pre-commit hooks and CI lint gates.
+
+  This is a **tooling lag** — the workflow is perfectly valid on GitHub.com and runs
+  correctly in hosted runners. The failure only occurs in local development environments
+  and CI pipelines that use act or actionlint for pre-flight validation.
+
+  SchemaStore (github-workflow.json) already encodes the `queue` enum, so VS Code's
+  GitHub Actions extension does NOT exhibit this error.
+fix: |
+  Until act and actionlint release updated versions with queue support, use one of:
+
+  1. Upgrade act to a version that includes PR #6097 (queue schema fix) — check
+     github.com/nektos/act for the minimum patched version.
+
+  2. Upgrade actionlint to a version that includes the fix for issue #657.
+
+  3. Skip schema validation for workflows that use queue (act: add --no-schema-valid flag;
+     actionlint: add -ignore 'queue' comment).
+
+  4. Temporarily remove queue: max while waiting for local tooling to catch up; GitHub.com
+     itself already supports it and local validation is the only blocker.
+fix_code:
+  - language: yaml
+    label: 'Correct workflow syntax — valid on GitHub.com even if local tools reject it'
+    code: |
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: false
+        queue: max    # queues up to 100 pending runs instead of cancelling them
+  - language: yaml
+    label: 'Suppress actionlint error with inline ignore comment'
+    code: |
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        cancel-in-progress: false
+        queue: max  # actionlint:ignore
+  - language: yaml
+    label: 'Skip act schema validation flag (temporary workaround)'
+    code: |
+      # In .actrc or CLI:
+      # act --no-schema-validate
+prevention:
+  - 'Pin act and actionlint versions in your tooling and monitor their changelogs when GitHub Actions releases new YAML keys.'
+  - 'When a workflow is valid on GitHub.com but rejected locally, check if it uses a recently-added key (queue, timezone, etc.) that local tools have not caught up with.'
+  - 'Use the SchemaStore github-workflow.json schema in VS Code for real-time validation — it tends to be updated faster than act/actionlint.'
+  - 'Do not block PR merges on local-only actionlint errors when the same workflow runs successfully in GitHub Actions CI.'
+docs:
+  - url: 'https://github.com/nektos/act/issues/6095'
+    label: 'nektos/act#6095 — concurrency.queue fails schema validation (May 2026)'
+  - url: 'https://github.com/rhysd/actionlint/issues/657'
+    label: 'rhysd/actionlint#657 — unknown key "queue" for concurrency'
+  - url: 'https://github.blog/changelog/2026-05-07-github-actions-concurrency-groups-now-allow-larger-queues/'
+    label: 'GitHub Changelog — concurrency groups now allow larger queues (May 2026)'
+  - url: 'https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#concurrencyqueue'
+    label: 'GitHub Docs — concurrency.queue syntax reference'

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

@@ -0,0 +1,103 @@
+id: yaml-syntax-073
+title: "setup-python 'python-version: 3.10' Parsed as YAML Float 3.1 — Wrong Python Version Installed"
+category: yaml-syntax
+severity: silent-failure
+tags:
+  - setup-python
+  - yaml-float
+  - python-version
+  - version-mismatch
+  - silent-failure
+patterns:
+  - regex: 'Version 3\.1 with arch .{0,20} not found'
+    flags: 'i'
+  - regex: "Installed Python 3\\.1\\."
+    flags: 'i'
+  - regex: 'python.version.*3\.10.*3\.1|3\.10.*yaml.*float'
+    flags: 'i'
+error_messages:
+  - "Version 3.1 with arch x64 not found in the local, remote file."
+  - "Version 3.1 with arch x64 not found"
+  - "Installed Python 3.1.5"
+  - "Error: Version 3.1 was not found in the local cache"
+root_cause: |
+  When 'python-version' is specified as a bare unquoted decimal like 3.10
+  in a workflow YAML file, the YAML parser interprets the value as a
+  floating-point number. The float representation of 3.10 is 3.1 (the
+  trailing zero is dropped during float-to-string conversion).
+
+  actions/setup-python then receives the string "3.1" and attempts to
+  install Python version 3.1.x. Python 3.1 is an extremely old release
+  from 2009 and is not available in the tool cache. The action either:
+
+  a) Fails with "Version 3.1 with arch x64 not found" — if the version
+     is not in the manifest (common on GitHub-hosted runners).
+  b) Silently installs the latest 3.1.x if one happens to be cached,
+     giving developers an unexpectedly old Python environment with no
+     warning.
+
+  Affected version strings: any Python version where the minor version
+  ends in zero (3.10, 3.20 if it existed, etc.) or has trailing decimal
+  zeros (3.10.0 → still has the problem if written unquoted as 3.10).
+
+  The same YAML float coercion affects other setup-* actions:
+  - setup-go with go-version: 1.20 → "1.2" (yaml-syntax-027)
+  - setup-node with node-version: 18.10 → "18.1"
+  This entry specifically covers setup-python.
+fix: |
+  Always quote the python-version value in YAML to force the parser to
+  treat it as a string, not a number.
+fix_code:
+  - language: yaml
+    label: "Wrong — unquoted 3.10 parsed as float 3.1"
+    code: |
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: 3.10   # ❌ YAML parses as float → installs 3.1.x
+
+  - language: yaml
+    label: "Fixed — quoted string forces correct version"
+    code: |
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.10'   # ✅ Quoted string → installs 3.10.x
+
+  - language: yaml
+    label: "Fixed — matrix with quoted python versions"
+    code: |
+      jobs:
+        test:
+          strategy:
+            matrix:
+              python-version: ['3.9', '3.10', '3.11', '3.12']
+              #               ^^^^^^  ^^^^^^  ^^^^^^  ^^^^^^
+              # All quoted — prevents YAML float coercion for any version
+          steps:
+            - uses: actions/setup-python@v5
+              with:
+                python-version: ${{ matrix.python-version }}
+
+  - language: yaml
+    label: "Alternative — use python-version-file to avoid manual version strings"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version-file: '.python-version'
+          # .python-version file contains: 3.10.14
+          # File-based version is read as plain text, not YAML — no float risk
+
+prevention:
+  - "Always quote python-version values in YAML: '3.10' not 3.10."
+  - "Use python-version-file: '.python-version' or pyproject.toml to read version from a non-YAML source."
+  - "Apply the same quoting rule to all setup-* version inputs: '1.20' for Go, '18.10' for Node."
+  - "Run actionlint — it warns about unquoted version strings in matrix definitions."
+  - "Check 'Set up Python' step output in the Actions log — it shows the resolved version string."
+docs:
+  - url: "https://github.com/actions/setup-python/issues/160"
+    label: "actions/setup-python#160 — python-version 3.10 parsed as float 3.1 (109 reactions)"
+  - url: "https://yaml.org/spec/1.2.2/#floating-point-scalars"
+    label: "YAML spec — floating-point scalar parsing rules"
+  - url: "https://github.com/actions/setup-python#supported-version-syntax"
+    label: "actions/setup-python — supported version syntax"

package/package.json

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