@htekdev/actions-debugger 1.0.37 → 1.0.39

package/errors/caching-artifacts/cache-legacy-service-decommission-url-override-fail.yml

@@ -0,0 +1,120 @@
+id: caching-artifacts-031
+title: 'Cache failures from manually-overridden ACTIONS_CACHE_URL after legacy service decommission (April 2025)'
+category: caching-artifacts
+severity: error
+tags:
+  - cache
+  - legacy-service
+  - ACTIONS_CACHE_URL
+  - service-migration
+  - brownout
+  - self-hosted
+patterns:
+  - regex: 'ACTIONS_CACHE_URL.*403|ACTIONS_CACHE_URL.*503|ACTIONS_CACHE_URL.*Connection refused'
+    flags: 'i'
+  - regex: 'Cache service responded with (403|503|5\d\d)'
+    flags: 'i'
+  - regex: 'Failed to restore cache entry\. Exiting\.\.\.'
+    flags: 'i'
+  - regex: 'Unable to reserve cache with key.*ACTIONS_CACHE_URL'
+    flags: 'i'
+error_messages:
+  - "Cache service responded with 503"
+  - "Cache service responded with 403"
+  - "Failed to restore cache entry. Exiting..."
+  - "Unable to reserve cache with key"
+  - "Error: ECONNREFUSED connecting to ACTIONS_CACHE_URL"
+root_cause: |
+  GitHub migrated all customers to a new cache service backend in early 2025
+  and decommissioned the legacy service on April 15, 2025. Prior to decommission,
+  brownout windows were scheduled on April 1 and April 8 (each 4-8 hours).
+
+  Workflows that explicitly override ACTIONS_CACHE_URL, ACTIONS_RESULTS_URL, or
+  ACTIONS_RUNTIME_URL continue routing requests to the decommissioned endpoint,
+  causing 403 or 503 responses. The cache action reports "Failed to restore cache
+  entry" or "Unable to reserve cache" and either skips caching silently or fails
+  the step (depending on fail-on-cache-miss settings).
+
+  Common sources of stale overrides:
+  - Third-party self-hosted runner software (ARC add-ons, Buildkite agents, etc.)
+    that inject a corporate cache proxy URL into the runner environment
+  - Composite actions or reusable workflows with hardcoded env var overrides
+    copied from pre-migration documentation
+  - Container images with ENV ACTIONS_CACHE_URL set in their Dockerfile,
+    inherited by container jobs and overriding the runner-injected value
+  - Enterprise self-hosted runner configurations in on-premises GitHub instances
+    that still point to a proxy configured for the old cache service API
+
+  The runner agent always injects the correct new-service values at job startup.
+  Any explicit override — even one set a millisecond earlier — takes precedence
+  and silently routes to the wrong endpoint.
+fix: |
+  Remove all explicit overrides of ACTIONS_CACHE_URL, ACTIONS_RESULTS_URL, and
+  ACTIONS_RUNTIME_URL from:
+  - Workflow env: blocks (top-level, job-level, and step-level)
+  - Composite action env blocks
+  - Reusable workflow env blocks
+  - Container image Dockerfiles (ENV directives)
+  - Self-hosted runner startup scripts and systemd unit files
+  - ARC runner controller configuration and any environment-injection middleware
+
+  Let the runner agent inject the correct values automatically at job startup.
+  These values are ephemeral per-job tokens — they cannot be cached or pre-set
+  and must come from the runner agent.
+
+  For self-hosted setups using a corporate cache proxy, update the proxy
+  to forward requests to the new service endpoint format, or decommission the
+  proxy if it is no longer required.
+fix_code:
+  - language: yaml
+    label: 'Remove ACTIONS_CACHE_URL override from workflow — let runner inject correct value'
+    code: |
+      # WRONG: overriding cache service URL causes failures after April 2025
+      # env:
+      #   ACTIONS_CACHE_URL: https://my-corp-proxy.example.com/_apis/artifactcache/
+      #   ACTIONS_RESULTS_URL: https://my-corp-proxy.example.com/_apis/
+      #   ACTIONS_RUNTIME_URL: https://my-corp-proxy.example.com/
+
+      # CORRECT: remove all overrides, let the runner inject the values
+      jobs:
+        build:
+          runs-on: [self-hosted, linux]
+          steps:
+            - uses: actions/checkout@v4
+            - name: Cache dependencies
+              uses: actions/cache@v4
+              with:
+                path: ~/.npm
+                key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+            - name: Install
+              run: npm ci
+  - language: yaml
+    label: 'Audit container images for hardcoded ACTIONS_CACHE_URL'
+    code: |
+      # In your Dockerfile — remove any hardcoded cache service URL
+      # FROM ubuntu:22.04
+      # ENV ACTIONS_CACHE_URL=https://...  ← REMOVE: causes failures after April 2025
+
+      # In your workflow — do not set cache URL env vars in container definitions
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          container:
+            image: myimage:latest
+            # Do not add env overrides for ACTIONS_CACHE_URL here
+          steps:
+            - uses: actions/cache@v4
+              with:
+                path: ~/.cache/pip
+                key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
+prevention:
+  - 'Never hardcode ACTIONS_CACHE_URL, ACTIONS_RESULTS_URL, or ACTIONS_RUNTIME_URL in workflows, container images, or runner configs'
+  - 'Audit third-party composite actions and runner middleware for injected cache URL overrides after any GitHub cache service migration'
+  - 'Subscribe to the GitHub Changelog (github.blog/changelog) to receive advance notice of cache service migrations and brownout schedules'
+  - 'Upgrade to actions/cache@v4 or later — the v4 client was updated to use the new service API and is the supported path forward'
+  - 'Add a pre-flight check step on self-hosted runners that logs the injected ACTIONS_CACHE_URL to detect unexpected overrides'
+docs:
+  - url: 'https://github.blog/changelog/2025-03-20-notification-of-upcoming-breaking-changes-in-github-actions/'
+    label: 'GitHub Changelog: Upcoming breaking changes — legacy cache service decommission (March 2025)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows'
+    label: 'Caching dependencies to speed up workflows — actions/cache@v4'

package/errors/runner-environment/container-job-rootless-user-workspace-eacces.yml

@@ -0,0 +1,103 @@
+id: runner-environment-097
+title: 'Container job with non-root Docker user fails with EACCES on workspace and command files'
+category: runner-environment
+severity: error
+tags:
+  - container-jobs
+  - non-root
+  - rootless
+  - permissions
+  - EACCES
+  - docker
+  - workspace
+patterns:
+  - regex: 'EACCES.*permission denied.*_runner_file_commands|permission denied.*_runner_file_commands'
+    flags: 'i'
+  - regex: 'permission denied.*GITHUB_ENV|permission denied.*GITHUB_OUTPUT|permission denied.*GITHUB_PATH|permission denied.*GITHUB_STEP_SUMMARY'
+    flags: 'i'
+  - regex: 'could not lock config file.*Permission denied'
+    flags: 'i'
+  - regex: 'EACCES.*permission denied.*__w|permission denied.*github/workspace'
+    flags: 'i'
+error_messages:
+  - "Error: EACCES: permission denied, open '/home/runner/work/_temp/_runner_file_commands/set_env_'"
+  - "Error: EACCES: permission denied, open '/__w/_temp/_runner_file_commands/add_path_'"
+  - "error: could not lock config file /home/runner/work/repo/.git/config: Permission denied"
+  - "EACCES: permission denied, open '/github/workspace/_temp/_runner_file_commands/'"
+root_cause: |
+  When a workflow uses a container job (jobs.<id>.container), the GitHub Actions
+  runner creates the workspace directories, .git directory, and all special command
+  files (GITHUB_ENV, GITHUB_OUTPUT, GITHUB_PATH, GITHUB_STEP_SUMMARY) as root UID
+  on the host before starting the container.
+
+  If the container image runs as a non-root user — via a USER directive in the
+  Dockerfile, docker run --user, or a Kubernetes securityContext.runAsUser setting —
+  that user has no write access to the root-owned files and directories. Every step
+  that writes to GITHUB_ENV, GITHUB_OUTPUT, GITHUB_PATH, or GITHUB_STEP_SUMMARY
+  fails with EACCES: permission denied. The checkout step also fails because git
+  cannot write the lock file for the config.
+
+  The runner does not automatically adjust ownership, set ACLs, or apply mount
+  options to make the workspace writable by non-root container users. This is a
+  known long-standing platform limitation tracked in runner#2411 (30 reactions)
+  with no built-in fix as of 2026. The issue also affects ARC (actions-runner-controller)
+  Kubernetes runners when the pod securityContext sets a non-root runAsUser.
+fix: |
+  Option 1 — Add `options: --user root` to the container definition.
+  This overrides the container USER and runs job steps as root, granting
+  full access to all runner-created files.
+
+  Option 2 — Set fsGroup in Kubernetes/ARC pod spec so mounted directories
+  are group-writable and the container's supplemental group matches.
+
+  Option 3 — Use a privileged init step (--user 0) to chown the workspace
+  to the container's non-root UID before executing actual build steps.
+
+  Option 4 — Build the container image with UID 1001 (the runner UID on
+  GitHub-hosted runners) instead of a custom non-root UID, so ownership
+  matches automatically.
+fix_code:
+  - language: yaml
+    label: 'Force container to run as root with options: --user root'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          container:
+            image: myapp:latest       # Has a non-root USER in its Dockerfile
+            options: --user root      # Override: run job steps as root
+          steps:
+            - uses: actions/checkout@v4
+            - name: Build
+              run: make build
+  - language: yaml
+    label: 'Set fsGroup in ARC RunnerSet to make workspace group-writable'
+    code: |
+      apiVersion: actions.github.com/v1alpha1
+      kind: RunnerSet
+      metadata:
+        name: my-runners
+      spec:
+        template:
+          spec:
+            securityContext:
+              fsGroup: 1001          # Match runner UID so workspace is accessible
+            containers:
+              - name: runner
+                image: ghcr.io/actions/actions-runner:latest
+                securityContext:
+                  runAsUser: 1001
+                  runAsGroup: 1001
+prevention:
+  - 'Prefer running container jobs as root or as UID 1001 to match the runner workspace ownership'
+  - 'Test container images locally with docker run --user <uid> to catch permission issues before CI'
+  - 'Document the --user root workaround in workflow templates that use custom container images'
+  - 'Consider using a job-level container for tool availability only, keeping privileged steps on the host runner'
+  - 'When building custom runner images, set USER to UID 1001 to match GitHub-hosted runner conventions'
+docs:
+  - url: 'https://github.com/actions/runner/issues/2411'
+    label: 'runner#2411: Runner does not set proper permissions for mounted folders in rootless container jobs (30 reactions)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-where-your-workflow-runs/running-jobs-in-a-container'
+    label: 'Running jobs in a container — options field and container configuration'
+  - url: 'https://github.com/actions/runner/issues/3290'
+    label: 'runner#3290: Kubernetes container pods fail with EACCES when using a custom user'

package/errors/runner-environment/macos-latest-macos-15-xcode16-sdk-mismatch.yml

@@ -0,0 +1,84 @@
+id: runner-environment-095
+title: macos-latest Points to macOS 15 — Xcode 16 Default Breaks Hardcoded SDK References
+category: runner-environment
+severity: error
+tags:
+  - macos-latest
+  - macos-15
+  - xcode-16
+  - runner-migration
+  - apple-silicon
+patterns:
+  - regex: 'SDK ''macosx14\.\d+'' cannot be located'
+    flags: i
+  - regex: 'SDKROOT.*macosx14'
+    flags: i
+  - regex: 'built for macOS 14.*linking for macOS 15'
+    flags: i
+  - regex: 'xcodebuild: error:.*SDK ''macosx14'
+    flags: i
+error_messages:
+  - "error: SDK 'macosx14.5' cannot be located"
+  - "xcodebuild: error: The requested SDK 'macosx14.5' cannot be found."
+  - "ld: warning: ignoring file ...: built for macOS 14, but linking for macOS 15"
+root_cause: |
+  GitHub updated macos-latest to point to macOS 15 (Sequoia) on Apple Silicon
+  (M1) runners in January 2025 (GitHub Changelog 2025-01-16). The macOS 15 runner
+  image ships with Xcode 16 as the default toolchain.
+
+  Workflows and Xcode project files that hardcode `SDKROOT=macosx14.5` or
+  `MACOSX_DEPLOYMENT_TARGET=14` fail because the macOS 14 SDK is not bundled
+  with Xcode 16 by default. Common failure modes:
+
+  - Hardcoded SDK version strings in .xcconfig files
+  - Xcode project targets specifying a minimum macOS deployment target of 14.x
+    that resolve against the now-absent SDK
+  - Homebrew formulae and pre-installed tool versions changed on macOS 15,
+    breaking workflows that assumed specific tool paths or versions
+  - The pre-installed Ruby version changed, breaking Fastlane and CocoaPods
+    workflows that did not pin a Ruby version
+fix: |
+  Option 1: Pin the runner to `macos-14` explicitly to continue using Xcode 15
+  and the macOS 14 SDK until you are ready to migrate.
+
+  Option 2: Use the `maxim-lobanov/setup-xcode` action to pin a specific Xcode
+  version on macos-latest, keeping the runner current while controlling toolchain.
+
+  Option 3: Update Xcode project settings to remove hardcoded SDK version strings.
+  Use `$(SDKROOT)` relative targets and set `MACOSX_DEPLOYMENT_TARGET` to a value
+  supported by Xcode 16.
+
+  For Ruby-dependent workflows (Fastlane, CocoaPods), use `ruby/setup-ruby` with
+  an explicit version rather than relying on the system Ruby.
+fix_code:
+  - language: yaml
+    label: Pin explicit macOS version to avoid macos-latest drift
+    code: |
+      jobs:
+        build:
+          runs-on: macos-14  # explicit; Xcode 15 + macOS 14 SDK
+
+  - language: yaml
+    label: Pin Xcode version on macos-latest
+    code: |
+      - uses: maxim-lobanov/setup-xcode@v1
+        with:
+          xcode-version: '15.4'
+
+  - language: yaml
+    label: Use ruby/setup-ruby for Fastlane and CocoaPods workflows
+    code: |
+      - uses: ruby/setup-ruby@v1
+        with:
+          ruby-version: '3.3'
+          bundler-cache: true
+prevention:
+  - "Pin explicit runner OS versions (macos-14, macos-15) instead of macos-latest for stable CI builds"
+  - "Never hardcode SDK version strings (macosx14.x) in Xcode project .xcconfig files — use $(SDKROOT)"
+  - "Use ruby/setup-ruby, actions/setup-python, and similar version-pinning actions for all language runtimes"
+  - "Subscribe to GitHub Changelog and runner-images repository releases for macOS image update notices"
+docs:
+  - url: https://github.blog/changelog/2025-01-16-github-actions-macos-15-is-now-the-latest-macos-runner-image/
+    label: "GitHub Changelog: macOS 15 becomes macos-latest (Jan 2025)"
+  - url: https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners
+    label: "GitHub-hosted runner images documentation"

package/errors/runner-environment/node16-actions-runtime-deprecated-disabled.yml

@@ -0,0 +1,87 @@
+id: runner-environment-094
+title: Node.js 16 Actions Runtime Deprecated and Disabled — Actions Using node16 Fail
+category: runner-environment
+severity: error
+tags:
+  - node16
+  - node20
+  - action-runtime
+  - deprecation
+  - runs-using
+patterns:
+  - regex: 'Node\.js 16 actions are deprecated'
+    flags: i
+  - regex: 'Please update the following actions to use Node\.js 20'
+    flags: i
+  - regex: 'uses a deprecated version of `actions/node`'
+    flags: i
+error_messages:
+  - "Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3"
+  - "Warning: Node.js 16 is End-of-Life. Upgrade to Node.js 20 or later."
+  - "Error: This request has been automatically failed because it uses a deprecated version of `actions/node`"
+root_cause: |
+  Node.js 16 reached end-of-life on September 11, 2023. GitHub announced on
+  September 22, 2023 (GitHub Changelog) that it would deprecate the Node.js 16
+  runtime for GitHub Actions, with a hard enforcement cutoff on September 22, 2024.
+
+  Actions authored with `runs.using: node16` in their action.yml emit deprecation
+  warnings from late 2023 onward. From September 2024, these actions produce hard
+  errors and may not execute. Third-party actions pinned to older major versions
+  that internally use node16 are affected, including actions/checkout@v3,
+  actions/setup-node@v3, actions/cache@v3, and many community actions. Composite
+  actions that transitively call a node16-based action also fail.
+fix: |
+  Update all action references in your workflows to major versions that use the
+  node20 (or node22) runtime. Common upgrades needed:
+  - actions/checkout@v3      → @v4
+  - actions/setup-node@v3    → @v4
+  - actions/cache@v3         → @v4
+  - actions/upload-artifact@v3 → @v4
+  - actions/download-artifact@v3 → @v4
+
+  For custom actions you own, update `runs.using` in action.yml from
+  `node16` to `node20`.
+
+  Use Dependabot or Renovate with the `github-actions` package ecosystem to
+  keep action versions current automatically.
+fix_code:
+  - language: yaml
+    label: Update official actions from node16 to node20-based versions
+    code: |
+      - uses: actions/checkout@v4           # was @v3 (node16)
+      - uses: actions/setup-node@v4         # was @v3 (node16)
+        with:
+          node-version: '20'
+      - uses: actions/cache@v4              # was @v3 (node16)
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+
+  - language: yaml
+    label: Update custom action.yml to node20 runtime
+    code: |
+      # In your action's action.yml
+      runs:
+        using: node20
+        main: dist/index.js
+
+  - language: yaml
+    label: Enable Dependabot for github-actions ecosystem
+    code: |
+      # .github/dependabot.yml
+      version: 2
+      updates:
+        - package-ecosystem: github-actions
+          directory: /
+          schedule:
+            interval: weekly
+prevention:
+  - "Enable Dependabot for the github-actions package ecosystem to receive automatic PRs for action version updates"
+  - "Audit all action.yml files in custom actions for runs.using: node16 before the hard cutoff"
+  - "Watch the actions/* repositories on GitHub for major version releases that upgrade the runtime"
+  - "Prefer Dependabot or Renovate over manually pinned major versions to stay ahead of deprecations"
+docs:
+  - url: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/
+    label: "GitHub Changelog: Transitioning from Node.js 16 to Node.js 20 (Sep 2023)"
+  - url: https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-javascript-actions
+    label: "Actions metadata syntax: runs.using"

package/errors/runner-environment/self-hosted-runsvc-zero-bytes-auto-update.yml

@@ -0,0 +1,112 @@
+id: runner-environment-096
+title: 'Self-hosted runner runsvc.sh corrupted to 0 bytes after auto-update'
+category: runner-environment
+severity: error
+tags:
+  - self-hosted
+  - auto-update
+  - runsvc
+  - systemd
+  - service-restart
+patterns:
+  - regex: 'runsvc\.sh.*0 bytes|0 bytes.*runsvc\.sh'
+    flags: 'i'
+  - regex: 'code=exited.*status=203/EXEC|status=203/EXEC'
+    flags: 'i'
+  - regex: 'Failed to start GitHub Actions Runner'
+    flags: 'i'
+  - regex: 'bin/runsvc\.sh.*Syntax error.*end of file'
+    flags: 'i'
+error_messages:
+  - "(code=exited, status=203/EXEC)"
+  - "Failed to start GitHub Actions Runner (svc.sh)"
+  - "bin/runsvc.sh: 1: Syntax error: Unexpected end of file"
+  - "bin.2.334.0/runsvc.sh: 0 bytes"
+root_cause: |
+  When a self-hosted runner auto-updates from v2.328.0 to v2.334.0 (and some
+  adjacent version pairs), a race condition in the update file-extraction process
+  sometimes writes the new bin.{version}/runsvc.sh as 0 bytes instead of the
+  correct shell script content.
+
+  The currently-running listener operates from in-memory state and continues
+  accepting and completing jobs normally — so the runner appears healthy in
+  the GitHub Actions UI and the corruption is not immediately visible. The
+  bin/runsvc.sh symlink quietly points to the corrupted 0-byte file.
+
+  On the next service restart (host reboot, manual systemctl restart, OOM kill,
+  scheduled maintenance window), systemd attempts to execute the 0-byte runsvc.sh,
+  receives Status=203/EXEC (exec format error because the file is empty), and the
+  runner fails to start entirely — dropping all pending and future jobs.
+
+  The failure is especially hard to diagnose because the runner appears fully
+  online right up to the restart event. Runners in pools that restart infrequently
+  may run corrupted for days before the symptom appears.
+fix: |
+  Immediate recovery:
+  1. Check if runsvc.sh is 0 bytes:
+       ls -lh /path/to/runner/bin/runsvc.sh
+  2. If 0 bytes, stop the service and re-download the runner package at the
+     same version, or manually copy runsvc.sh from a known-good runner
+     installation of the same version.
+  3. Restart the service and confirm it comes up cleanly before re-enabling
+     job acceptance.
+
+  Preventive measures:
+  - Disable auto-update (--no-auto-update flag during registration) and manage
+    runner version upgrades manually during maintenance windows.
+  - Add a startup health check (see fix_code) that verifies runsvc.sh is
+    non-zero before the service is considered ready.
+  - For ephemeral runners, use container restart policies that detect the
+    0-byte condition and re-register a fresh runner instead of recycling
+    a corrupted one.
+fix_code:
+  - language: yaml
+    label: 'Detect corrupted runsvc.sh in a pre-job health check step'
+    code: |
+      jobs:
+        preflight:
+          runs-on: [self-hosted, linux]
+          steps:
+            - name: Verify runner service script integrity
+              shell: bash
+              run: |
+                RUNNER_SVC="$(dirname "$(realpath "$0")")/../bin/runsvc.sh"
+                if [ ! -s "$RUNNER_SVC" ]; then
+                  echo "::error::runsvc.sh is 0 bytes — runner update corrupted the service script. Re-register this runner."
+                  exit 1
+                fi
+                echo "runsvc.sh OK ($(wc -c < "$RUNNER_SVC") bytes)"
+  - language: yaml
+    label: 'Pin runner version and disable auto-update via ARC RunnerSet spec'
+    code: |
+      # actions-runner-controller RunnerSet — pin version, disable auto-update
+      apiVersion: actions.github.com/v1alpha1
+      kind: RunnerSet
+      metadata:
+        name: my-runners
+      spec:
+        githubConfigUrl: https://github.com/my-org/my-repo
+        githubConfigSecret: controller-manager
+        minRunners: 2
+        maxRunners: 10
+        template:
+          spec:
+            containers:
+              - name: runner
+                image: ghcr.io/actions/actions-runner:2.334.0   # pin version
+                env:
+                  - name: DISABLE_RUNNER_UPDATE
+                    value: '1'
+prevention:
+  - 'Pin runner version with --no-auto-update and upgrade manually during maintenance windows'
+  - 'Monitor runner systemd units with alerting on failed states before jobs queue up'
+  - 'Use ephemeral runners (--ephemeral flag) so each job gets a freshly registered runner, avoiding accumulated update corruption'
+  - 'After any auto-update event, verify that bin/runsvc.sh is non-zero before accepting production jobs'
+  - 'Run a nightly canary workflow that exercises a restart-then-run cycle on self-hosted pools'
+docs:
+  - url: 'https://github.com/actions/runner/issues/4421'
+    label: 'runner#4421: runsvc.sh sometimes 0 bytes after auto-update from 2.328.0 to 2.334.0 (May 2026)'
+  - url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners'
+    label: 'Autoscaling with self-hosted runners — runner lifecycle management'
+  - url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-version-updates'
+    label: 'Self-hosted runner version updates'

package/errors/runner-environment/ubuntu-latest-ubuntu-24-python2-package-removal.yml

@@ -0,0 +1,75 @@
+id: runner-environment-093
+title: ubuntu-latest Now Points to Ubuntu 24.04 — Python 2 and Legacy Packages Removed
+category: runner-environment
+severity: error
+tags:
+  - ubuntu-latest
+  - ubuntu-24-04
+  - python2
+  - apt-get
+  - runner-migration
+patterns:
+  - regex: 'E: Package ''python'' has no installation candidate'
+    flags: i
+  - regex: 'python: command not found'
+    flags: i
+  - regex: 'Unable to locate package python2'
+    flags: i
+  - regex: 'E: Package ''libssl1\.1'' has no installation candidate'
+    flags: i
+error_messages:
+  - "E: Package 'python' has no installation candidate"
+  - "python: command not found"
+  - "Unable to locate package python2"
+  - "E: Package 'libssl1.1' has no installation candidate"
+root_cause: |
+  GitHub changed ubuntu-latest to point to Ubuntu 24.04 on November 7, 2024
+  (announced via GitHub Changelog on September 25, 2024). Ubuntu 24.04 (Noble
+  Numbat) removes several packages that were present on Ubuntu 20.04 and 22.04:
+
+  - The `python` package (Python 2.7) is entirely absent; only `python3` is available
+  - `python2` and `python-is-python2` are not installable via apt
+  - `libssl1.1` (OpenSSL 1.1.x) is removed; only OpenSSL 3.x ships with 24.04
+  - Various other legacy apt packages dropped in the 24.04 LTS release
+
+  Workflows that ran `sudo apt-get install python`, invoked `python script.py`
+  (instead of `python3`), or installed packages transitively depending on
+  libssl1.1 started failing immediately after the image switch.
+fix: |
+  Option 1: Replace all `python` calls with `python3` and use `actions/setup-python`
+  to install a specific Python 3 version rather than relying on the system default.
+
+  Option 2: Pin the runner to `ubuntu-22.04` explicitly if Python 2 is genuinely
+  required or if you need time to migrate. Note that ubuntu-22.04 will eventually
+  be retired from the GitHub-hosted runner fleet.
+
+  Audit all `apt-get install` steps for packages removed in Ubuntu 24.04, including
+  libssl1.1, python2, python-is-python2, libffi7, and others listed in the Ubuntu
+  24.04 release notes.
+fix_code:
+  - language: yaml
+    label: Use actions/setup-python and replace python with python3
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+
+      - name: Run script
+        run: python3 script.py
+
+  - language: yaml
+    label: Pin explicit runner version to avoid ubuntu-latest drift
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-22.04  # explicit version; do not rely on ubuntu-latest
+prevention:
+  - "Pin explicit runner versions (ubuntu-22.04, ubuntu-24.04) instead of ubuntu-latest to prevent surprise image changes"
+  - "Use actions/setup-python for all Python installs rather than apt-get"
+  - "Replace python with python3 in all shell commands and scripts"
+  - "Subscribe to GitHub Changelog for runner image update announcements before they take effect"
+docs:
+  - url: https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/
+    label: "GitHub Changelog: ubuntu-latest points to Ubuntu 24.04 (Sep 2024)"
+  - url: https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners
+    label: "GitHub-hosted runner images documentation"

package/errors/silent-failures/fork-pr-secrets-empty-string-steps-silently-skipped.yml

@@ -0,0 +1,97 @@
+id: silent-failures-042
+title: Fork pull_request Secrets Are Empty Strings — Secret-Gated Steps Silently Skip
+category: silent-failures
+severity: silent-failure
+tags:
+  - fork
+  - pull-request
+  - secrets
+  - empty-string
+  - conditional-step
+patterns:
+  - regex: 'secrets\.[A-Z_]+ != ''''.*if.*condition'
+    flags: i
+  - regex: 'npm ERR! code E401'
+    flags: ''
+  - regex: 'Error: HttpError: Resource not accessible by integration'
+    flags: i
+error_messages:
+  - "npm ERR! code E401"
+  - "Error: HttpError: Resource not accessible by integration"
+  - "(No log output — the step shows 'skipped' status when secrets.MY_TOKEN != '' evaluates false on fork PRs)"
+root_cause: |
+  When a pull_request event is triggered from a fork, GitHub Actions intentionally
+  provides empty strings ("") for all secrets in the `secrets` context — not null,
+  but empty string. This is a security measure to prevent secret exfiltration from
+  untrusted fork code running in the base repository's context.
+
+  The silent-failure pattern occurs when a workflow guards a step with a secrets
+  check:
+
+    - if: ${{ secrets.NPM_TOKEN != '' }}
+      run: npm publish
+
+  On fork PRs, `secrets.NPM_TOKEN` is `""`, so the condition evaluates to `false`
+  and the step is silently skipped with no error, no warning, and no indication
+  in normal logs. Developers expecting either a published artifact or a clear
+  failure instead see a green workflow with a quietly skipped deploy step.
+
+  A related failure mode: when the empty secret IS used directly (without a guard),
+  the downstream tool emits a generic auth error (E401, 403) that gives no indication
+  the root cause is an empty secret from a fork trigger.
+fix: |
+  Separate concerns: run untrusted fork code in a `pull_request` workflow (no
+  secrets needed), then gate secret-requiring operations on a `workflow_run`
+  workflow that triggers after the pull_request workflow completes. The
+  workflow_run event runs in the base branch context and has full access to
+  repository secrets.
+
+  If you must use secrets in a `pull_request` workflow (e.g., to post PR comments
+  via GITHUB_TOKEN), rely on the automatically-provided GITHUB_TOKEN with
+  appropriate `permissions:` — do not depend on user-defined secrets in
+  pull_request context from forks.
+
+  Avoid the `if: ${{ secrets.MY_SECRET != '' }}` guard pattern entirely;
+  document the fork limitation explicitly in the workflow file instead.
+fix_code:
+  - language: yaml
+    label: "Split pattern: pull_request for tests (no secrets), workflow_run for deploys"
+    code: |
+      # pr-tests.yml — runs untrusted fork code, no secrets needed
+      on: pull_request
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: npm ci && npm test
+
+  - language: yaml
+    label: workflow_run continuation with secrets (runs in base branch context)
+    code: |
+      # pr-deploy.yml — triggers after pr-tests completes; has full secret access
+      on:
+        workflow_run:
+          workflows: [PR Tests]
+          types: [completed]
+      jobs:
+        publish:
+          if: ${{ github.event.workflow_run.conclusion == 'success' }}
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: npm publish
+              env:
+                NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+prevention:
+  - "Never write if: ${{ secrets.MY_SECRET != '' }} as a fork guard — this silently evaluates false on all fork PRs"
+  - "Use the pull_request + workflow_run split pattern for any workflow needing both fork code and repository secrets"
+  - "Add a comment in your workflow file explaining that secret-gated steps intentionally skip on fork PRs"
+  - "Use GITHUB_TOKEN with explicit permissions: blocks for operations that only require base repository access"
+docs:
+  - url: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-secrets
+    label: "GitHub Docs: Security hardening for GitHub Actions — using secrets"
+  - url: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
+    label: "GitHub Security Lab: Preventing pwn requests (pull_request_target risks)"
+  - url: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run
+    label: "GitHub Docs: workflow_run event"

package/errors/silent-failures/github-workspace-incorrect-inside-container-job.yml

@@ -0,0 +1,123 @@
+id: silent-failures-043
+title: 'github.workspace and runner.workspace return host paths, not container paths, inside container jobs'
+category: silent-failures
+severity: silent-failure
+tags:
+  - container-jobs
+  - github-context
+  - workspace
+  - path-mismatch
+  - expressions
+  - silent
+patterns:
+  - regex: '\$\{\{\s*github\.workspace\s*\}\}.*container|\$\{\{\s*runner\.workspace\s*\}\}.*container'
+    flags: 'i'
+  - regex: '/home/runner/work/[^/]+/[^/]+.*no such file|not found.*home/runner/work'
+    flags: 'i'
+error_messages: []
+root_cause: |
+  Inside container jobs, `${{ github.workspace }}` and `${{ runner.workspace }}`
+  resolve to the HOST-side path (e.g., /home/runner/work/repo/repo), not the
+  path that the container actually sees at runtime (e.g., /github/workspace or
+  /__w/repo/repo depending on the runner type).
+
+  The container mounts the workspace at a different path than the host. Any
+  expression using these context values to construct file paths, Docker build
+  contexts, artifact paths, or shell script arguments will silently resolve to
+  the wrong location inside the container — either a non-existent path or an
+  unexpected host directory leaked into the container mount namespace.
+
+  By contrast, the GITHUB_WORKSPACE and RUNNER_WORKSPACE environment variables
+  ARE injected with the correct container-visible paths. Only the expression
+  context values (${{ github.workspace }}) are wrong. This inconsistency is the
+  core trap: developers expect context and env var to be equivalent, but inside
+  containers they diverge.
+
+  No error is raised — wrong paths are silently accepted by shells and tools,
+  causing subtly incorrect behavior: files not found, wrong directory used for
+  builds, artifacts uploaded from wrong paths, or test results pointing to
+  non-existent locations.
+
+  Tracked in runner#2058 (81 reactions, 13 confused reactions) as a known bug
+  with no built-in fix as of 2026.
+fix: |
+  Use the GITHUB_WORKSPACE environment variable instead of the
+  ${{ github.workspace }} expression inside container job steps. The env var
+  is injected by the runner with the correct container-visible path.
+
+  Similarly, use RUNNER_WORKSPACE instead of ${{ runner.workspace }}.
+
+  For Docker build contexts and tool paths that require absolute paths, use
+  the container-visible path directly:
+  - GitHub-hosted runners: /github/workspace
+  - ARC/self-hosted: /__w/<repo-name>/<repo-name> (verify with pwd in first step)
+
+  Alternatively, use relative paths (.) wherever possible to avoid the
+  host/container path discrepancy entirely.
+fix_code:
+  - language: yaml
+    label: 'Use GITHUB_WORKSPACE env var instead of ${{ github.workspace }} inside container steps'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          container:
+            image: myapp-builder:latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # WRONG: returns host path, not the container-visible mount path
+            # - name: Build
+            #   run: cd "${{ github.workspace }}" && make build
+
+            # CORRECT: GITHUB_WORKSPACE is set to the container-visible path
+            - name: Build
+              run: |
+                echo "Container workspace: $GITHUB_WORKSPACE"
+                cd "$GITHUB_WORKSPACE" && make build
+  - language: yaml
+    label: 'Use relative paths for Docker build context inside container jobs'
+    code: |
+      jobs:
+        docker-in-docker:
+          runs-on: ubuntu-latest
+          container:
+            image: docker:24
+          steps:
+            - uses: actions/checkout@v4
+            - name: Build image
+              run: |
+                # Use . (current dir) not ${{ github.workspace }} for build context
+                docker build -t myimage:latest .
+
+                # If absolute path needed, use the env var:
+                docker build -t myimage:latest "$GITHUB_WORKSPACE"
+  - language: yaml
+    label: 'Debug step to reveal the actual container workspace path'
+    code: |
+      jobs:
+        debug:
+          runs-on: ubuntu-latest
+          container:
+            image: ubuntu:22.04
+          steps:
+            - name: Show path discrepancy
+              run: |
+                echo "Host path via context (WRONG inside container):"
+                echo "  github.workspace = ${{ github.workspace }}"
+                echo ""
+                echo "Container-visible path via env var (CORRECT):"
+                echo "  GITHUB_WORKSPACE = $GITHUB_WORKSPACE"
+                echo ""
+                echo "Actual current directory: $(pwd)"
+prevention:
+  - 'Never use ${{ github.workspace }} or ${{ runner.workspace }} expressions inside container job steps — they return host paths'
+  - 'Use the GITHUB_WORKSPACE and RUNNER_WORKSPACE environment variables for all path references inside containers'
+  - 'Use relative paths wherever possible in container steps to avoid the host/container path mismatch entirely'
+  - 'Add a debug step printing both the context value and the env var when authoring new container workflows'
+  - 'Test container-based workflows locally with nektos/act to surface path resolution issues before CI'
+docs:
+  - url: 'https://github.com/actions/runner/issues/2058'
+    label: 'runner#2058: github.workspace and runner.workspace are incorrect inside container jobs (81 reactions)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-where-your-workflow-runs/running-jobs-in-a-container'
+    label: 'Running jobs in a container — environment variables and context values'

package/package.json

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