@htekdev/actions-debugger 1.0.57 → 1.0.59

package/errors/caching-artifacts/caching-artifacts-040.yml

@@ -0,0 +1,112 @@
+id: caching-artifacts-040
+title: "actions/download-artifact@v4 cross-workflow download silently returns no artifacts without actions: read permission"
+category: caching-artifacts
+severity: error
+tags:
+  - download-artifact
+  - v4
+  - cross-workflow
+  - permissions
+  - actions-read
+  - run-id
+  - breaking-change
+patterns:
+  - regex: 'Unable to find any artifacts for the associated workflow'
+    flags: 'i'
+  - regex: 'No artifacts found for the associated workflow run'
+    flags: 'i'
+  - regex: 'run-id:.*\d+'
+    flags: 'i'
+  - regex: 'Resource not accessible by integration'
+    flags: 'i'
+error_messages:
+  - "Unable to find any artifacts for the associated workflow"
+  - "No artifacts found for the associated workflow run"
+  - "Resource not accessible by integration"
+  - "Error: Artifact download failed: 403 Forbidden"
+root_cause: |
+  actions/download-artifact@v4 introduced the ability to download artifacts produced
+  by a *different* workflow run (not just the current run) by specifying the `run-id`
+  input. This cross-workflow download requires the `actions: read` permission on the
+  GITHUB_TOKEN.
+
+  Workflows that do not explicitly declare `permissions: actions: read` will use the
+  default GITHUB_TOKEN permissions. In repositories where the default token permissions
+  are set to "read for all" at the org level, `actions` read may be granted by default
+  — but in repositories with restrictive default permissions or when only specific
+  permissions are declared in the workflow, `actions: read` is NOT automatically
+  included.
+
+  The misleading aspect is the error message: "Unable to find any artifacts for the
+  associated workflow" suggests the artifact does not exist, when in fact the issue is
+  a 403 permission denial. The action does not distinguish between "artifact not found"
+  and "access denied" in its error output.
+
+  This is a new permission requirement introduced in v4 that did not exist in v3
+  (which only supported downloading from the current workflow run and did not need
+  `actions` read access).
+
+  Common trigger scenario: a workflow that processes artifacts from a different trigger
+  (e.g., a deployment workflow that downloads build artifacts from a build workflow run)
+  is upgraded from download-artifact@v3 to @v4 and the `run-id` input is added — but
+  the required `permissions: actions: read` block is not added.
+fix: |
+  Add `actions: read` to the permissions block of the job or workflow that uses
+  `actions/download-artifact@v4` with a `run-id` input referencing a different workflow.
+
+  If the workflow or job already has a `permissions` block, add `actions: read` to it.
+  If there is no `permissions` block, add one with the minimum required permissions
+  including `actions: read` and `contents: read`.
+fix_code:
+  - language: yaml
+    label: "Add actions: read permission for cross-workflow artifact download"
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          permissions:
+            actions: read    # Required for download-artifact@v4 with run-id
+            contents: read
+          steps:
+            - name: Download build artifacts from build workflow
+              uses: actions/download-artifact@v4
+              with:
+                name: build-output
+                run-id: ${{ github.event.inputs.build_run_id }}
+                github-token: ${{ secrets.GITHUB_TOKEN }}
+  - language: yaml
+    label: "Workflow-level permissions for cross-workflow download"
+    code: |
+      on:
+        workflow_dispatch:
+          inputs:
+            build_run_id:
+              description: 'Run ID of the build workflow'
+              required: true
+              type: string
+
+      permissions:
+        actions: read
+        contents: read
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/download-artifact@v4
+              with:
+                name: dist
+                run-id: ${{ inputs.build_run_id }}
+                github-token: ${{ secrets.GITHUB_TOKEN }}
+prevention:
+  - "Whenever `run-id` is added to a download-artifact@v4 step, immediately add `actions: read` to the job permissions block"
+  - "Do not rely on default token permissions for cross-workflow operations — always declare explicit permission blocks"
+  - "Test cross-workflow downloads in a feature branch before merging — the permission error is deterministic, not flaky"
+  - "Add `github-token: ${{ secrets.GITHUB_TOKEN }}` explicitly to download-artifact@v4 steps that use run-id, as it clarifies the token in use"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-workflow-data-as-artifacts#downloading-artifacts-from-a-previous-workflow-run"
+    label: "GitHub Docs — Downloading artifacts from a previous workflow run"
+  - url: "https://github.com/actions/download-artifact/releases/tag/v4.0.0"
+    label: "actions/download-artifact v4.0.0 release notes — cross-workflow download"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token#defining-access-for-the-github_token-scopes"
+    label: "GitHub Docs — GITHUB_TOKEN permission scopes"

package/errors/permissions-auth/permissions-auth-042.yml

@@ -0,0 +1,125 @@
+id: permissions-auth-042
+title: "actions/attest-build-provenance requires both id-token: write AND attestations: write — missing attestations permission causes 403"
+category: permissions-auth
+severity: error
+tags:
+  - attestations
+  - attest-build-provenance
+  - id-token
+  - permissions
+  - supply-chain
+  - sigstore
+  - 403
+patterns:
+  - regex: 'attestations.*write.*required|write.*attestations.*required'
+    flags: 'i'
+  - regex: 'Resource not accessible by integration.*attest'
+    flags: 'i'
+  - regex: 'Error: Failed to create attestation'
+    flags: 'i'
+  - regex: 'permissions.*attestations.*write'
+    flags: 'i'
+error_messages:
+  - "Error: Failed to create attestation: Resource not accessible by integration"
+  - "Error: Failed to create attestation: 403 Forbidden"
+  - "RequestError [HttpError]: Resource not accessible by integration"
+  - "Error: Attestation creation failed: must have `attestations: write` permission"
+root_cause: |
+  GitHub's artifact attestation feature (GA May 2024, https://github.blog/changelog/2024-05-02-github-artifact-attestations-is-generally-available/)
+  allows workflows to generate Sigstore-compatible provenance attestations for build
+  artifacts using `actions/attest-build-provenance` or `actions/attest`.
+
+  These actions require TWO permissions on the GITHUB_TOKEN:
+  1. `id-token: write` — to fetch an OIDC token from GitHub's identity provider
+     (used to sign the attestation with Sigstore)
+  2. `attestations: write` — to store the attestation in GitHub's attestation store
+     (new permission introduced with the attestation feature)
+
+  Most early documentation examples, blog posts, and quickstarts only show
+  `id-token: write`, omitting `attestations: write`. Developers following these
+  examples get a cryptic 403 "Resource not accessible by integration" error when
+  the attest step runs, with no clear indication that a second permission is missing.
+
+  The error is consistent and not environment-specific — it will fail on every run
+  until the `attestations: write` permission is added.
+
+  Additionally, organization-level policies may restrict the use of attestations.
+  If the organization has disabled artifact attestations, the 403 will occur even
+  with both permissions present — the error message does not distinguish between
+  "missing permission" and "feature disabled by org policy".
+fix: |
+  Add BOTH `id-token: write` AND `attestations: write` to the permissions block
+  of the job that runs the attest-build-provenance action.
+
+  If your workflow or job already declares a `permissions` block, add both entries
+  to it. If your workflow has no permissions block, add one with both required
+  permissions plus any other permissions your workflow needs (e.g., `contents: read`
+  for checkout).
+
+  Note: `attestations: write` is only available on github.com. GitHub Enterprise
+  Server (GHES) requires GHES 3.12+ for attestation support.
+fix_code:
+  - language: yaml
+    label: "Correct permissions for actions/attest-build-provenance"
+    code: |
+      jobs:
+        build-and-attest:
+          runs-on: ubuntu-latest
+          permissions:
+            id-token: write      # Required: OIDC token for Sigstore signing
+            attestations: write  # Required: write attestation to GitHub store
+            contents: read       # Required: checkout
+
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build artifact
+              run: |
+                npm ci
+                npm run build
+                tar -czf dist.tar.gz dist/
+
+            - name: Generate build provenance attestation
+              uses: actions/attest-build-provenance@v2
+              with:
+                subject-path: dist.tar.gz
+  - language: yaml
+    label: "Attest multiple subjects (container image + artifact)"
+    code: |
+      jobs:
+        release:
+          runs-on: ubuntu-latest
+          permissions:
+            id-token: write
+            attestations: write
+            contents: read
+            packages: write  # If pushing to GHCR
+
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Attest binary
+              uses: actions/attest-build-provenance@v2
+              with:
+                subject-path: bin/myapp
+
+            - name: Attest container image
+              uses: actions/attest-build-provenance@v2
+              with:
+                subject-name: ghcr.io/${{ github.repository }}/myapp
+                subject-digest: ${{ steps.push.outputs.digest }}
+                push-to-registry: true
+prevention:
+  - "Always include BOTH `id-token: write` and `attestations: write` in the permissions block — neither alone is sufficient"
+  - "Copy the permissions block from the official actions/attest-build-provenance README examples, not from third-party blog posts"
+  - "Use `gh attestation verify <artifact>` locally to test that attestations were created successfully after the workflow runs"
+  - "For GHES deployments, verify the GHES version is 3.12+ before adding attestation steps to workflows"
+docs:
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds"
+    label: "GitHub Docs — Using artifact attestations to establish provenance"
+  - url: "https://github.blog/changelog/2024-05-02-github-artifact-attestations-is-generally-available/"
+    label: "GitHub Changelog — Artifact attestations GA (May 2024)"
+  - url: "https://github.com/actions/attest-build-provenance"
+    label: "actions/attest-build-provenance — README and required permissions"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token"
+    label: "GitHub Docs — GITHUB_TOKEN permission scopes (attestations: write)"

package/errors/runner-environment/runner-environment-118.yml

@@ -0,0 +1,102 @@
+id: runner-environment-118
+title: "Node.js 20 actions deprecated — forced to Node.js 24 runtime starting June 16, 2026"
+category: runner-environment
+severity: warning
+tags:
+  - node-20
+  - node-24
+  - deprecation
+  - actions-runtime
+  - checkout
+  - setup-node
+  - self-hosted-runner
+patterns:
+  - regex: 'Node\.js 20 actions are deprecated'
+    flags: 'i'
+  - regex: 'forced to run with Node\.js 24 by default'
+    flags: 'i'
+  - regex: 'using:\s*node20'
+    flags: 'i'
+  - regex: 'ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION'
+    flags: 'i'
+error_messages:
+  - "Node.js 20 actions are deprecated. Actions will be forced to run with Node.js 24 by default starting June 16th, 2026."
+  - "Node.js 20 will be removed from the runner on September 16th, 2026."
+  - "Please check if updated versions of these actions are available that support Node.js 24."
+root_cause: |
+  GitHub deprecated Node.js 20 as the runtime for GitHub Actions in September 2025
+  (https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/).
+  Starting June 16, 2026, actions that declare `using: node20` are force-upgraded to
+  Node.js 24 on hosted runners. Node.js 20 will be fully removed from hosted runners
+  on September 16, 2026.
+
+  This affects two distinct scenarios:
+
+  1. First-party GitHub-maintained actions (actions/checkout@v4, actions/setup-node@v4,
+     actions/upload-artifact@v4, etc.) — GitHub is updating these actions to ship Node.js 24
+     variants. Pinning to older major versions (e.g., @v4 without updating) will trigger
+     the deprecation warning until updated versions are pinned.
+
+  2. Community and custom actions that declare `using: node20` in their action.yml —
+     these will be silently force-upgraded to Node.js 24, which may break actions that
+     rely on Node.js 20 APIs, native modules compiled for Node 20, or behavior differences
+     between Node 20 and Node 24 (e.g., stricter URL parsing, OpenSSL changes).
+
+  3. Self-hosted runners with Node.js 18/20 installed — if the runner does not have
+     Node.js 24 available and FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 is set to true, the
+     action will fail to find a suitable runtime.
+
+  The deprecation warning appears as an annotation on every workflow run that uses an
+  affected action. While currently advisory, it becomes a hard failure on September 16, 2026.
+fix: |
+  Update all first-party GitHub actions to their latest versions that ship Node.js 24
+  support. For actions/checkout, setup-node, upload-artifact, download-artifact, and
+  other official actions, check the latest release tag.
+
+  For self-hosted runners, install Node.js 24 on the runner host before June 16, 2026.
+
+  For custom or community actions you maintain, update action.yml to declare
+  `using: node24` and update package.json to target Node.js 24.
+
+  To opt in early and test Node.js 24 behavior before the forced cutover, set the
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 environment variable to `true` in your workflow
+  or at the runner level.
+fix_code:
+  - language: yaml
+    label: "Update first-party actions to Node.js 24 compatible versions"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            # Update to latest versions that support Node.js 24
+            - uses: actions/checkout@v4.2.2        # or latest v5 when available
+            - uses: actions/setup-node@v4.1.0      # or latest
+            - uses: actions/upload-artifact@v4.4.0 # or latest
+            - uses: actions/download-artifact@v4.2.0
+  - language: yaml
+    label: "Opt in early to Node.js 24 for testing"
+    code: |
+      env:
+        FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: 'true'
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run build
+              run: npm ci && npm run build
+prevention:
+  - "Pin actions to specific minor versions (e.g., @v4.2.2) and use Dependabot or Renovate to auto-update them"
+  - "Add FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true to workflow env to test Node.js 24 compatibility before the forced cutover"
+  - "For self-hosted runners, ensure Node.js 24 is installed and available on PATH before June 16, 2026"
+  - "Audit custom actions in your organization for `using: node20` declarations and update them to `using: node24`"
+  - "Subscribe to the GitHub Changelog (https://github.blog/changelog/) to catch runtime deprecations early"
+docs:
+  - url: "https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/"
+    label: "GitHub Changelog — Deprecation of Node.js 20 on GitHub Actions runners (Sept 2025)"
+  - url: "https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runsusing"
+    label: "GitHub Docs — Action metadata syntax: runs.using"
+  - url: "https://nodejs.org/en/about/previous-releases"
+    label: "Node.js release schedule — LTS lifecycle"

package/errors/runner-environment/runner-environment-119.yml

@@ -0,0 +1,98 @@
+id: runner-environment-119
+title: "ubuntu-24.04 GCC 13 treats implicit function declarations as hard errors in C"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu-24
+  - gcc-13
+  - c-compilation
+  - implicit-declaration
+  - breaking-change
+  - ubuntu-latest
+patterns:
+  - regex: 'error: implicit declaration of function'
+    flags: 'i'
+  - regex: '\[-Wimplicit-function-declaration\]'
+    flags: 'i'
+  - regex: 'implicit declaration of function .* is invalid in C99'
+    flags: 'i'
+  - regex: 'cc1: some warnings being treated as errors'
+    flags: 'i'
+error_messages:
+  - "error: implicit declaration of function 'foo' [-Wimplicit-function-declaration]"
+  - "implicit declaration of function 'getline' is invalid in C99 [-Wimplicit-function-declaration]"
+  - "cc1: some warnings being treated as errors"
+  - "error: 'strdup' undeclared (first use in this function)"
+root_cause: |
+  ubuntu-24.04 runners ship with GCC 13.2.0, replacing GCC 11.4.0 on ubuntu-22.04.
+  GCC 13 promotes several previously-warning-level diagnostics to hard errors in C
+  compilation. The most commonly triggered change is -Wimplicit-function-declaration:
+  calling a function without a prior declaration or prototype is now an error, not
+  a warning. This matches the requirement in the C99, C11, and C23 standards, but
+  was only enforced as a warning in earlier GCC versions.
+
+  Workflows that compiled successfully on ubuntu-22.04 (GCC 11) now fail on
+  ubuntu-24.04 (GCC 13) with "error: implicit declaration of function" even when
+  the source code has not changed. Common triggers:
+  - Missing #include directives for standard library functions (getline, strtok_r,
+    strdup, getaddrinfo, etc.)
+  - Using POSIX-only functions without _GNU_SOURCE or _POSIX_C_SOURCE feature macros
+  - Legacy C code or vendored dependencies not maintained for C99 compliance
+
+  Additional GCC 13 diagnostics upgraded from warnings to errors:
+  - -Wint-conversion: assigning int where pointer is expected (and vice versa)
+  - -Wincompatible-pointer-types: passing incompatible pointer type to a function
+
+  The ubuntu-latest label resolves to ubuntu-24.04 as of 2025. Workflows that
+  previously used ubuntu-latest and relied on GCC 11 behavior are now affected
+  even without changing their runner label.
+fix: |
+  Preferred fix: correct the source code by adding missing #include directives
+  or explicit function prototypes. This is the standards-compliant approach and
+  permanently resolves the issue.
+
+  Temporary suppression: add -Wno-implicit-function-declaration (and optionally
+  -Wno-int-conversion, -Wno-incompatible-pointer-types) to CFLAGS in the build
+  step. This restores GCC 11 behavior for vendored or unmaintained C code but
+  should be treated as a short-term workaround only.
+
+  Short-term runner pin: use runs-on: ubuntu-22.04 while fixing the source.
+  ubuntu-22.04 will eventually be retired from GitHub-hosted runners.
+fix_code:
+  - language: yaml
+    label: "Add suppression flags to CFLAGS for legacy C code"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build with legacy C compatibility flags
+              run: |
+                make CFLAGS="-O2 -Wno-implicit-function-declaration \
+                              -Wno-int-conversion \
+                              -Wno-incompatible-pointer-types"
+  - language: yaml
+    label: "Pin to ubuntu-22.04 temporarily while fixing source"
+    code: |
+      jobs:
+        build:
+          # TODO: fix implicit declarations then migrate back to ubuntu-24.04
+          runs-on: ubuntu-22.04
+          steps:
+            - uses: actions/checkout@v4
+            - run: make
+prevention:
+  - "Run builds on ubuntu-24.04 in a matrix alongside ubuntu-22.04 to detect GCC 13 errors before fully migrating"
+  - "Add all required #include headers — GCC 13 enforces what the C standard has required since C99"
+  - "Use -Wno-error=implicit-function-declaration as a transitional flag rather than disabling the warning entirely"
+  - "Audit vendored C libraries for GCC 13 compatibility before upgrading runner images"
+  - "Enable -Wall in CI early to surface implicit declaration warnings before they become hard errors"
+docs:
+  - url: "https://gcc.gnu.org/gcc-13/porting_to.html"
+    label: "GCC 13 porting guide — new errors and behavioral changes"
+  - url: "https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md"
+    label: "ubuntu-24.04 runner image — installed software (GCC 13.2.0)"
+  - url: "https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html"
+    label: "GCC warning options — -Wimplicit-function-declaration"

package/errors/runner-environment/runner-environment-120.yml

@@ -0,0 +1,118 @@
+id: runner-environment-120
+title: "snap install fails on GitHub-hosted runners — snapd daemon not available"
+category: runner-environment
+severity: error
+tags:
+  - snap
+  - snapd
+  - ubuntu
+  - package-manager
+  - runner-limitation
+  - apt-alternative
+patterns:
+  - regex: 'snap.*command not found|command not found.*snap'
+    flags: 'i'
+  - regex: 'cannot communicate with server.*snapd\.sock'
+    flags: 'i'
+  - regex: 'dial unix /run/snapd\.sock.*no such file or directory'
+    flags: 'i'
+  - regex: 'error: cannot connect to the snap daemon'
+    flags: 'i'
+error_messages:
+  - "sudo: snap: command not found"
+  - "error: cannot communicate with server: Post \"http://localhost/v2/snaps/...\": dial unix /run/snapd.sock: connect: no such file or directory"
+  - "error: cannot connect to the snap daemon"
+  - "/bin/sh: 1: snap: not found"
+root_cause: |
+  GitHub-hosted runner images (ubuntu-22.04, ubuntu-24.04, and ubuntu-latest) do
+  not include the snapd daemon and do not support the snap package manager.
+
+  Snapd requires a persistent background daemon (snapd.service) and specific kernel
+  configuration for confinement (AppArmor profiles, seccomp filters) that is not
+  available or not configured in the ephemeral VM environment GitHub uses for
+  hosted runners. Even if the snap binary were present, the daemon is not running,
+  causing all snap commands to fail at the IPC socket connection step.
+
+  This limitation surprises developers who routinely use snap packages on local
+  Ubuntu workstations and attempt to replicate those install commands in CI.
+  Common affected workflows:
+  - Installing tools distributed primarily or exclusively via snap (certain IoT,
+    embedded, or cross-compile toolchains; some cloud CLI tools)
+  - Reproducing local Ubuntu developer setup scripts in CI verbatim
+  - CI pipelines for snap packages themselves (snap build requires LXD or snapcraft)
+
+  The error "cannot communicate with server: dial unix /run/snapd.sock: no such
+  file or directory" is deterministic — it fails on every run, not intermittently.
+fix: |
+  Replace snap install commands with an equivalent alternative:
+
+  1. APT: Most tools available as snaps also have apt packages. Check
+     packages.ubuntu.com for the apt equivalent (the version may be older).
+
+  2. Direct binary / official releases: Many developer tools (kubectl, helm,
+     terraform, go, etc.) publish standalone binaries on GitHub Releases or
+     their official download pages.
+
+  3. Official setup-* actions: GitHub and tool vendors maintain actions/setup-go,
+     azure/setup-kubectl, hashicorp/setup-terraform, etc. that install tools
+     cleanly without snap.
+
+  4. Docker: Run the snap-packaged tool inside a Docker container if no other
+     distribution method exists (the snap itself cannot run inside Docker, but
+     the underlying tool usually has a Docker image).
+
+  For snap package development and testing (e.g., snapcraft builds), use a
+  self-hosted runner with LXD configured, or the snapcore/action-build action
+  which handles the LXD setup automatically.
+fix_code:
+  - language: yaml
+    label: "Replace snap install with apt or official action"
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Instead of: sudo snap install kubectl --classic
+            - name: Set up kubectl (official action)
+              uses: azure/setup-kubectl@v4
+              with:
+                version: 'v1.30.0'
+
+            # Instead of: sudo snap install terraform
+            - name: Set up Terraform (official action)
+              uses: hashicorp/setup-terraform@v3
+              with:
+                terraform_version: "1.9.0"
+
+            - run: kubectl version --client
+  - language: yaml
+    label: "Build snap packages with snapcore/action-build (handles LXD)"
+    code: |
+      jobs:
+        snapcraft:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build snap
+              uses: snapcore/action-build@v1
+
+            - name: Upload snap artifact
+              uses: actions/upload-artifact@v4
+              with:
+                name: my-snap
+                path: '*.snap'
+prevention:
+  - "Check the GitHub Actions Marketplace for an official setup-* action before reaching for snap"
+  - "Use direct binary downloads from tool vendors' GitHub Releases when no setup-* action exists"
+  - "Avoid copying local Ubuntu setup scripts verbatim into CI — apt/brew/direct-download are the CI-safe equivalents"
+  - "Self-hosted runners on Ubuntu can have snapd installed if snap packages are genuinely required"
+docs:
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software"
+    label: "GitHub Docs — Pre-installed software on GitHub-hosted runners"
+  - url: "https://github.com/snapcore/action-build"
+    label: "snapcore/action-build — official snap build action (uses LXD)"
+  - url: "https://snapcraft.io/docs/build-on-github"
+    label: "Snapcraft Docs — Building snaps on GitHub Actions"

package/errors/runner-environment/runner-environment-121.yml

@@ -0,0 +1,113 @@
+id: runner-environment-121
+title: "macOS-15 and macOS-26 Apple system Ruby (/usr/bin/ruby 2.6) removed — bare ruby and gem commands fail"
+category: runner-environment
+severity: error
+tags:
+  - macos-15
+  - macos-26
+  - ruby
+  - system-ruby
+  - gem
+  - cocoapods
+  - breaking-change
+patterns:
+  - regex: '/usr/bin/ruby.*[Nn]o such file|[Nn]o such file.*/usr/bin/ruby'
+    flags: 'i'
+  - regex: 'ruby: No such file or directory'
+    flags: 'i'
+  - regex: 'rbenv: version .* is not installed'
+    flags: 'i'
+  - regex: 'Your Ruby version is .*, but your Gemfile specified'
+    flags: 'i'
+error_messages:
+  - "/usr/bin/ruby: No such file or directory"
+  - "bash: /usr/bin/ruby: No such file or directory"
+  - "rbenv: version '2.6.10' is not installed"
+  - "Your Ruby version is 3.3.4, but your Gemfile specified ~> 2.6"
+  - "[!] CocoaPods requires your terminal to be using UTF-8 encoding. Consider adding the following to ~/.profile: export LANG=en_US.UTF-8"
+root_cause: |
+  Apple removed the system Ruby installation (/usr/bin/ruby, version 2.6.10) from
+  macOS 15 Sequoia. This Ruby shipped as part of macOS since macOS 10.5 and was
+  installed at /usr/bin/ruby via Xcode Command Line Tools. It was used as the
+  runtime for Bundler, CocoaPods, Fastlane, and other Ruby-based iOS/macOS build
+  tools that shipped their own invocation scripts pointing to /usr/bin/ruby.
+
+  GitHub-hosted macOS-15 and macOS-26 runner images reflect this Apple change.
+  macOS-14 runners still include /usr/bin/ruby 2.6.10. GitHub pre-installs Ruby 3.3
+  via rbenv on macOS-15 and macOS-26, but:
+
+  1. Scripts or Makefiles that explicitly reference /usr/bin/ruby fail immediately
+     with "No such file or directory"
+  2. Gemfiles pinned to ruby "~> 2.6" fail — pre-installed Ruby is 3.3.x
+  3. CocoaPods legacy install scripts (including some older Fastfiles) called
+     /usr/bin/ruby directly; those fail on macOS-15 runners
+  4. rbenv configurations referencing the Apple system Ruby slot (2.6.10) fail
+     with "rbenv: version '2.6.10' is not installed"
+  5. brew install ruby may install a different version than expected, and its
+     PATH precedence may conflict with rbenv-managed Ruby
+
+  The macOS-latest label resolves to macOS-15 and eventually macOS-26 as Apple
+  releases new macOS versions. Workflows using macOS-latest are affected even
+  without changing their runner specification.
+fix: |
+  Use the ruby/setup-ruby action to install and pin a specific Ruby version.
+  This is the recommended approach for all macOS GitHub Actions workflows and
+  works correctly on macOS-14, macOS-15, and macOS-26.
+
+  For CocoaPods: add a Gemfile with the cocoapods gem and use Bundler
+  (bundle exec pod install) instead of calling pod directly. This also gives
+  reproducible CocoaPods version pinning across all environments.
+
+  Search the repository for any hardcoded /usr/bin/ruby references before
+  migrating to macOS-15 runners.
+fix_code:
+  - language: yaml
+    label: "Use ruby/setup-ruby to install and pin Ruby (recommended)"
+    code: |
+      jobs:
+        build:
+          runs-on: macos-15
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Set up Ruby
+              uses: ruby/setup-ruby@v1
+              with:
+                ruby-version: '3.3'
+                bundler-cache: true  # runs bundle install automatically
+
+            - name: Run tests
+              run: bundle exec rspec
+  - language: yaml
+    label: "CocoaPods via Bundler — replace direct pod invocation"
+    code: |
+      jobs:
+        ios-build:
+          runs-on: macos-15
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: ruby/setup-ruby@v1
+              with:
+                ruby-version: '3.3'
+                bundler-cache: true
+
+            # Gemfile must include: gem 'cocoapods', '~> 1.15'
+            - name: Install pods via Bundler
+              run: bundle exec pod install
+              working-directory: ios/
+prevention:
+  - "Never hardcode /usr/bin/ruby — always invoke ruby via PATH after ruby/setup-ruby"
+  - "Add ruby/setup-ruby with an explicit ruby-version to every macOS workflow that uses Ruby, Bundler, or CocoaPods"
+  - "Pin CocoaPods in a Gemfile and use bundle exec pod install — not the global pod command"
+  - "Search CI scripts and Fastfiles for /usr/bin/ruby before migrating to macOS-15 or macOS-26 runners"
+  - "Use the macos-15 label explicitly in CI for testing before it becomes the macos-latest default"
+docs:
+  - url: "https://github.com/ruby/setup-ruby"
+    label: "ruby/setup-ruby action — official Ruby installer for GitHub Actions"
+  - url: "https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md"
+    label: "GitHub Actions macOS-15 runner image — installed software"
+  - url: "https://guides.cocoapods.org/using/a-gemfile.html"
+    label: "CocoaPods — using a Gemfile (Bundler-based installation)"
+  - url: "https://www.ruby-lang.org/en/documentation/installation/"
+    label: "Ruby installation options — setup-ruby vs system Ruby"

package/errors/runner-environment/runner-environment-122.yml

@@ -0,0 +1,134 @@
+id: runner-environment-122
+title: "ubuntu-24.04 cgroup v2 only — Docker containers and JVMs built for cgroup v1 fail"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu-24
+  - cgroup-v2
+  - docker
+  - systemd-in-container
+  - java
+  - kubernetes
+  - breaking-change
+patterns:
+  - regex: 'cgroup.*v1.*not supported|v1.*cgroup.*not available'
+    flags: 'i'
+  - regex: 'failed to create.*cgroup|cgroup.*permission denied'
+    flags: 'i'
+  - regex: 'write.*cgroup.*read-only file system|cgroup.*read.only'
+    flags: 'i'
+  - regex: 'OCI runtime create failed.*cgroup'
+    flags: 'i'
+error_messages:
+  - "OCI runtime create failed: cgroup v1 not supported on this system"
+  - "Error response from daemon: failed to create shim task: cgroup v1 is not available"
+  - "failed to create cgroup: write /sys/fs/cgroup/memory/docker/...: read-only file system"
+  - "cannot enter cgroupv2 namespace: invalid argument"
+root_cause: |
+  ubuntu-24.04 GitHub-hosted runners use Linux kernel 6.5+ with cgroup v2 (the
+  unified hierarchy) exclusively. cgroup v1 subsystems are not mounted and not
+  available. ubuntu-22.04 runners supported both cgroup v1 and v2 simultaneously
+  (the hybrid mode enabled in the 5.x kernel era), so containers built for v1
+  worked without modification.
+
+  This affects four main workflow categories:
+
+  1. systemd-in-container testing: Docker images using systemd as PID 1 (Ansible
+     role tests, Molecule, infrastructure integration tests) require cgroup v2
+     support in the container's systemd version. Images based on older base images
+     (Ubuntu 18.04, CentOS 7/8, RHEL 7) with systemd < 248 fail to start because
+     their systemd was compiled for the cgroup v1 hierarchy.
+
+  2. Old JVM containers: JVM releases before JDK 11u16, JDK 17u4, and JDK 19+
+     do not correctly detect container memory and CPU limits under cgroup v2.
+     These JVMs either crash with OutOfMemoryError (using the host memory limit
+     instead of the container limit) or report the wrong available processor count.
+
+  3. Kubernetes-in-Docker (kind, k3d): older versions of kind (pre-v0.17) and k3d
+     fail to initialize cluster nodes due to cgroup v2 incompatibility in the
+     bundled containerd or runc version.
+
+  4. eBPF and networking tools: eBPF programs that attach to cgroup v1 BPF program
+     type (BPF_PROG_TYPE_CGROUP_SOCK, etc.) using the v1 subsystem hierarchy fail
+     because the v1 cgroup paths (/sys/fs/cgroup/memory/, /sys/fs/cgroup/cpu/)
+     are not present.
+
+  The ubuntu-latest label resolved to ubuntu-24.04 in 2025. Workflows that relied
+  on ubuntu-latest and had cgroup v1 dependent containers are now affected.
+fix: |
+  1. Update base images to cgroup v2 compatible versions:
+     - systemd: use Ubuntu 22.04+ or Debian Bookworm base images (systemd 249+)
+     - Java: update to JDK 11.0.16+, JDK 17.0.4+, or JDK 19+ (full cgroup v2 support)
+     - kind: use v0.17.0+ which ships containerd 1.7+ with cgroup v2 support
+     - k3d: use v5.6.0+
+
+  2. For systemd containers: mount /sys/fs/cgroup with rw access and use
+     --cgroupns=host if the container requires the host cgroup namespace
+
+  3. Pin to ubuntu-22.04 as a short-term workaround while updating container images.
+     ubuntu-22.04 will eventually be retired from GitHub-hosted runners.
+fix_code:
+  - language: yaml
+    label: "Run systemd containers with cgroup v2 compatible mounts"
+    code: |
+      jobs:
+        ansible-test:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Start systemd container (cgroup v2 compatible)
+              run: |
+                docker run -d \
+                  --name test-node \
+                  --cgroupns=host \
+                  --tmpfs /tmp \
+                  --tmpfs /run \
+                  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
+                  ubuntu:22.04
+
+            - name: Run Ansible role test
+              run: docker exec test-node ansible-playbook site.yml
+  - language: yaml
+    label: "Use kind v0.17+ for Kubernetes-in-Docker on ubuntu-24.04"
+    code: |
+      jobs:
+        k8s-test:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Create kind cluster (v0.17+ required for cgroup v2)
+              uses: helm/kind-action@v1
+              with:
+                version: v0.23.0
+                cluster_name: test-cluster
+
+            - run: kubectl cluster-info
+  - language: yaml
+    label: "Pin to ubuntu-22.04 temporarily for cgroup v1 dependent workflows"
+    code: |
+      jobs:
+        integration-test:
+          # TODO: update container images to cgroup v2 compatible versions
+          runs-on: ubuntu-22.04
+          steps:
+            - uses: actions/checkout@v4
+            - run: docker compose up -d
+prevention:
+  - "Test Docker container images on ubuntu-24.04 before migrating — check cgroup v2 compatibility with `docker run --rm ubuntu:24.04 ls /sys/fs/cgroup/`"
+  - "Use JDK 17.0.4+ or JDK 21+ in all containerized Java workloads for correct cgroup v2 memory/CPU detection"
+  - "Audit Dockerfiles for hardcoded cgroup v1 subsystem paths (/sys/fs/cgroup/memory/, /sys/fs/cgroup/cpu/)"
+  - "Use kind v0.17+ and k3d v5.6+ for Kubernetes-in-Docker CI on ubuntu-24.04"
+  - "Base images on Ubuntu 22.04+ or Debian Bookworm for any container running systemd as PID 1"
+docs:
+  - url: "https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html"
+    label: "Linux kernel — cgroup v2 unified hierarchy documentation"
+  - url: "https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md"
+    label: "ubuntu-24.04 runner image — kernel version and installed software"
+  - url: "https://kind.sigs.k8s.io/docs/user/known-issues/#pod-errors-due-to-too-many-open-files"
+    label: "kind known issues — cgroup v2 and containerd requirements"
+  - url: "https://docs.docker.com/engine/security/userns-remap/"
+    label: "Docker — cgroup v2 compatibility and container isolation"
+  - url: "https://bugs.openjdk.org/browse/JDK-8230305"
+    label: "OpenJDK — JDK-8230305: Container Metrics: Support cgroup v2 (fixed in JDK 15, backported 11u16/17u4)"

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

@@ -0,0 +1,104 @@
+id: silent-failures-059
+title: "ubuntu-latest label changed to ubuntu-24.04 — workflows silently regress without any code change"
+category: silent-failures
+severity: silent-failure
+tags:
+  - ubuntu-latest
+  - ubuntu-24.04
+  - runner-label
+  - breaking-change
+  - silent-regression
+  - changelog
+patterns:
+  - regex: 'runs-on:\s*ubuntu-latest'
+    flags: 'i'
+  - regex: 'GITHUB_ENV.*ubuntu-24\.04'
+    flags: 'i'
+  - regex: 'ImageVersion.*24\.04'
+    flags: 'i'
+error_messages:
+  - "ubuntu-latest now points to ubuntu-24.04"
+  - "ImageVersion: 24.04"
+  - "DISTRIB_CODENAME=noble"
+root_cause: |
+  GitHub periodically updates the `ubuntu-latest` runner label to point to a newer
+  Ubuntu LTS release. When GitHub updated `ubuntu-latest` from ubuntu-22.04 to
+  ubuntu-24.04, workflows using `runs-on: ubuntu-latest` silently started running on
+  a different operating system with no error, no annotation, and no workflow file change.
+
+  This is a silent failure because:
+  - The workflow YAML file is unchanged
+  - GitHub Actions does not emit any warning when the label target changes
+  - Workflow run logs show "ubuntu-24.04" only in the runner image annotation, which
+    many developers don't actively monitor
+  - All jobs complete with exit code 0 even though the software environment changed
+
+  Ubuntu 24.04 (Noble) introduced multiple breaking changes relative to 22.04 (Jammy):
+  - Python 3.12 as default (removes distutils, changes pip behavior)
+  - OpenSSL 3.3 with stricter TLS renegotiation defaults
+  - nftables replaces iptables (breaks Docker networking setups using iptables rules)
+  - python3-distutils apt package removed
+  - python alias may not resolve to python3 in all contexts
+  - libssl1.1 removed (only libssl3 available)
+  - Various default package versions changed (gcc, make, cmake)
+
+  Any workflow that relied on implicit ubuntu-22.04 behavior while pinning only
+  `ubuntu-latest` is at risk of silent behavioral changes, test flakiness, or
+  hard build failures that appear unrelated to any code change.
+fix: |
+  Pin the runner to an explicit Ubuntu version to opt out of automatic label
+  updates. Use `runs-on: ubuntu-22.04` if you need the previous behavior, or
+  explicitly migrate to `runs-on: ubuntu-24.04` and verify all workflow steps
+  work correctly.
+
+  To identify which runner version you are actually running, add a diagnostic step:
+
+  ```bash
+  echo "Runner: $RUNNER_OS $ImageVersion"
+  lsb_release -a
+  ```
+
+  Review each ubuntu-24.04 breaking change that applies to your workflow and
+  address them before pinning to ubuntu-24.04. See the related runner-environment
+  entries for specific package and API breakages.
+fix_code:
+  - language: yaml
+    label: "Pin to explicit Ubuntu version instead of ubuntu-latest"
+    code: |
+      jobs:
+        build:
+          # Pin explicitly instead of ubuntu-latest to avoid silent label updates
+          runs-on: ubuntu-22.04   # or ubuntu-24.04 after testing
+
+          # To migrate to 24.04, test explicitly first:
+          # runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+            - name: Show runner info
+              run: lsb_release -a && python3 --version
+  - language: yaml
+    label: "Matrix strategy to test across Ubuntu versions before committing"
+    code: |
+      jobs:
+        test:
+          strategy:
+            matrix:
+              os: [ubuntu-22.04, ubuntu-24.04]
+          runs-on: ${{ matrix.os }}
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run tests
+              run: npm test
+prevention:
+  - "Never use `ubuntu-latest` in production workflows — pin to an explicit version (ubuntu-22.04, ubuntu-24.04)"
+  - "Subscribe to GitHub Changelog announcements for runner label change notices before they go live"
+  - "Add a matrix build that tests both current and next Ubuntu LTS versions as part of ongoing CI"
+  - "Include a step that prints `lsb_release -a` to make runner version visible in logs without digging into annotations"
+  - "When migrating to a new Ubuntu version, run `apt-cache policy <package>` to verify package availability before deploying"
+docs:
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources"
+    label: "GitHub Docs — Supported runners (ubuntu-latest current target)"
+  - url: "https://github.blog/changelog/2025-01-16-github-actions-all-actions-on-ubuntu-latest-will-now-be-run-on-ubuntu-24-04/"
+    label: "GitHub Changelog — ubuntu-latest updated to ubuntu-24.04"
+  - url: "https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md"
+    label: "runner-images — Ubuntu 24.04 pre-installed software list"

package/package.json

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