@htekdev/actions-debugger 1.0.70 → 1.0.72

package/errors/known-unsolved/copilot-code-review-consumes-actions-minutes.yml

@@ -0,0 +1,103 @@
+id: known-unsolved-044
+title: 'Copilot code review consumes GitHub Actions minutes on private repositories — unexpected billing from June 1, 2026'
+category: known-unsolved
+severity: limitation
+tags:
+  - copilot
+  - copilot-code-review
+  - billing
+  - actions-minutes
+  - private-repos
+  - spending-limit
+patterns:
+  - regex: 'copilot.*code.*review.*actions.*minutes'
+    flags: 'i'
+  - regex: 'spending limit.*github actions'
+    flags: 'i'
+  - regex: 'exceeded.*spending limit.*copilot'
+    flags: 'i'
+error_messages:
+  - 'GitHub Actions minutes unexpectedly consumed by Copilot code review jobs'
+  - 'Actions billing spike after enabling Copilot code review on private repositories'
+root_cause: |
+  Starting June 1, 2026, GitHub Copilot code review shifted to an agentic tool-calling
+  architecture that runs on GitHub Actions using GitHub-hosted runners. As a result, each
+  Copilot code review on a private repository now consumes GitHub Actions minutes in addition
+  to Copilot AI Credits (under the new usage-based billing model).
+
+  This is not an error in your workflow — your existing workflows are unaffected. The issue
+  is an invisible, automatic Actions workflow that GitHub creates and runs internally for
+  each Copilot code review request on your private repos. The runner time shows up in your
+  Actions billing dashboard as unexpected consumption.
+
+  Affected plans:
+  - GitHub Copilot Pro
+  - GitHub Copilot Pro+
+  - GitHub Copilot Business
+  - GitHub Copilot Enterprise
+  This also includes Copilot code reviews from non-licensed users billed via direct org billing.
+
+  The behavior is by design and cannot be disabled — if Copilot code review is active on
+  private repos, Actions minutes will be consumed. The rate depends on the runner type:
+  - Standard GitHub-hosted runners: standard per-minute Actions rates apply
+  - Larger runners: billed at the larger runner rate
+  - Self-hosted runners: no additional Actions minute charges (self-hosted runner costs apply)
+
+  Organizations that had spending limits set low for Actions (or spending limits set to $0)
+  may find that Copilot code reviews start being blocked when the Actions spending limit is hit,
+  causing the review to fail or not run at all — without a clear error message explaining why.
+
+  There is no way to separate "Copilot code review Actions minutes" from regular workflow
+  Actions minutes in the billing dashboard — they are aggregated together.
+fix: |
+  There is no way to opt out of Actions minute consumption for Copilot code review on private
+  repos while keeping Copilot code review enabled. The available mitigations are:
+
+  1. **Use self-hosted runners**: Configure Copilot code review to use self-hosted runners.
+     Self-hosted runner usage does not count toward your GitHub Actions minute allowance.
+     This is the only way to eliminate the per-review Actions minute charge.
+
+  2. **Increase the Actions spending limit**: Review your organization's Actions spending limit
+     in Settings → Billing & Plans → Spending limits. Ensure the limit covers the expected
+     volume of Copilot code reviews in addition to your regular Actions usage.
+
+  3. **Set up budget controls**: Use GitHub's usage-based billing budget controls to set
+     per-user or organization-wide spending caps for Actions to prevent surprise overages.
+
+  4. **Monitor proactively**: Use GitHub Actions metrics and the Billing Usage Report to
+     track combined Actions + Copilot consumption before the end of the billing cycle.
+
+  5. **Public repositories**: Copilot code review on public repositories does not consume
+     Actions minutes (Actions minutes remain free for public repos).
+fix_code:
+  - language: yaml
+    label: 'No workflow change needed — this is a billing configuration issue, not a workflow error'
+    code: |
+      # There is no workflow YAML to change.
+      # To use self-hosted runners for Copilot code review, configure the runner
+      # in your organization or repository settings:
+      #   Settings → Actions → Runners → Add runner
+      # Then configure Copilot code review to use that runner label.
+      #
+      # To check your Actions spending limit:
+      #   Settings → Billing & Plans → Spending limits → GitHub Actions
+      #
+      # Example: setting up a budget alert for Actions usage
+      # (done in GitHub UI or via REST API, not workflow YAML)
+      #
+      # Regular workflows are unaffected — no changes needed to existing .yml files.
+prevention:
+  - 'Before enabling Copilot code review on private repositories, review your current GitHub Actions spending limit and adjust if needed'
+  - 'Monitor Actions usage in the first billing cycle after enabling Copilot code review to calibrate expected consumption'
+  - 'Configure self-hosted runners for Copilot code review to eliminate per-review Actions minute charges'
+  - 'Set an explicit Actions spending limit (not $0) to avoid Copilot reviews silently failing when the limit is hit'
+  - 'Public repositories are exempt — Copilot code review on public repos does not consume Actions minutes'
+docs:
+  - url: 'https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/'
+    label: 'GitHub Changelog: Copilot code review will start consuming Actions minutes on June 1, 2026'
+  - url: 'https://github.blog/changelog/2026-06-01-updates-to-github-copilot-billing-and-plans/'
+    label: 'GitHub Changelog: Copilot billing updates — usage-based billing is active (June 1, 2026)'
+  - url: 'https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions'
+    label: 'GitHub Docs: About billing for GitHub Actions'
+  - url: 'https://docs.github.com/en/copilot/github-copilot-enterprise/copilot-code-review/using-github-copilot-code-review'
+    label: 'GitHub Docs: Using GitHub Copilot code review'

package/errors/known-unsolved/ubuntu-arm64-images-frozen-github-transition.yml

@@ -0,0 +1,114 @@
+id: known-unsolved-045
+title: 'ubuntu-24.04-arm and ubuntu-22.04-arm runner images paused during GitHub Arm64 takeover — no package updates during transition'
+category: known-unsolved
+severity: limitation
+tags:
+  - arm64
+  - ubuntu-arm
+  - runner-images
+  - partner-runner-images
+  - package-updates
+  - security-updates
+patterns:
+  - regex: 'ubuntu-24\.04-arm'
+    flags: 'i'
+  - regex: 'ubuntu-22\.04-arm'
+    flags: 'i'
+  - regex: 'partner-runner-images'
+    flags: 'i'
+error_messages:
+  - 'No recent runner-images release notes for ubuntu-24.04-arm during migration period'
+  - 'Package version pinned to stale ubuntu-arm runner image during GitHub transition'
+root_cause: |
+  In May 2026, GitHub announced it was taking ownership of the Arm64 runner images for
+  GitHub Actions hosted runners, transitioning them away from Arm Limited, LLC (previously
+  maintained in the actions/partner-runner-images repository).
+
+  During this transition period:
+  - ubuntu-24.04-arm and ubuntu-22.04-arm images WILL NOT receive updates
+  - No new release notes appear in actions/runner-images for these images during migration
+  - The actions/partner-runner-images repository is being archived
+  - All open issues and future support are moving to actions/runner-images
+
+  This means workflows running on ubuntu-24.04-arm or ubuntu-22.04-arm during the
+  transition period (May 2026 until migration completes) are running on stale images that
+  may have:
+  - Unpatched security vulnerabilities (CVEs disclosed after the freeze date)
+  - Missing package versions that were released after the freeze date
+  - Outdated tool versions (e.g., Docker, Node.js, Python) compared to the x86 equivalents
+
+  The exact duration of the freeze is not published — GitHub states "during the transition."
+  Developers who pin specific package or tool versions that are only available in newer
+  releases may find those versions unavailable on arm runners while they are available on
+  the x86 equivalents.
+
+  This is a known, intentional operational decision by GitHub during the infrastructure
+  migration. There is no error message — workflows simply run on stale images silently.
+fix: |
+  There is no immediate fix since the image freeze is a deliberate infrastructure choice
+  during the migration. Available mitigations:
+
+  1. **Track the migration status**: Monitor the actions/runner-images repository for
+     announcements about when the Ubuntu Arm64 images resume updates. GitHub has indicated
+     the partner-runner-images repo will be archived after the transition completes.
+
+  2. **Report critical issues directly**: For CVEs or critical vulnerabilities in the arm
+     images during the transition, open an issue in actions/runner-images (NOT
+     actions/partner-runner-images, which is being archived).
+
+  3. **Avoid pinning to specific recent package versions on arm runners**: If your workflow
+     installs packages with exact version pinning, add a fallback or use the latest available
+     version rather than a specific recent release that may not be in the frozen image.
+
+  4. **Use self-hosted Arm64 runners**: If the image freeze causes unacceptable security or
+     tool-version risk, consider switching to self-hosted Arm64 runners where you control
+     the image update cadence.
+
+  5. **Test cross-architecture differences**: If workflows behave differently on x86 vs arm
+     during this period, check whether the discrepancy is due to the arm image being stale
+     rather than a genuine architecture difference.
+fix_code:
+  - language: yaml
+    label: 'Use self-hosted Arm64 runner to bypass the frozen GitHub-hosted arm image'
+    code: |
+      jobs:
+        arm-build:
+          # Temporarily use a self-hosted arm runner if the GitHub-hosted arm image
+          # is missing security patches or required packages during the migration period.
+          # Replace with ubuntu-24.04-arm once GitHub resumes image updates.
+          runs-on: self-hosted-arm64
+
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Build on Arm64
+              run: make build
+
+  - language: yaml
+    label: 'Avoid pinning exact recent package versions on arm runners during the transition'
+    code: |
+      jobs:
+        arm-build:
+          runs-on: ubuntu-24.04-arm
+          steps:
+            - uses: actions/checkout@v4
+
+            # AVOID: pinning to a very recent package version that may not be in frozen image
+            # - run: apt-get install -y libexample=2.6.3-1
+
+            # PREFER: install latest available version from the frozen image's apt cache
+            - run: |
+                sudo apt-get update
+                sudo apt-get install -y libexample
+prevention:
+  - 'Monitor actions/runner-images (not actions/partner-runner-images) for Ubuntu Arm64 image update resumption announcements'
+  - 'For security-sensitive workloads on arm runners, track CVE advisories against the frozen image versions until the transition completes'
+  - 'Avoid cross-architecture version pinning assumptions — package versions on arm images may lag x86 images during the transition period'
+  - 'Open issues for Arm64 runner image problems in actions/runner-images — the partner-runner-images repository is being archived and will no longer receive support'
+docs:
+  - url: 'https://github.blog/changelog/2026-05-14-github-actions-upcoming-image-migrations/'
+    label: 'GitHub Changelog: GitHub Actions Upcoming image migrations — Arm64 takeover (May 2026)'
+  - url: 'https://github.com/actions/runner-images'
+    label: 'actions/runner-images — new home for all runner image issues including Arm64'
+  - url: 'https://github.com/actions/partner-runner-images'
+    label: 'actions/partner-runner-images — being archived after Arm64 transition completes'

package/errors/runner-environment/actions-core-v3-esm-only-require-fails.yml

@@ -0,0 +1,136 @@
+id: runner-environment-131
+title: '@actions/core 3.0.0 is ESM-only — custom JavaScript actions using require() fail with ERR_REQUIRE_ESM'
+category: runner-environment
+severity: error
+tags:
+  - esm
+  - commonjs
+  - actions-core
+  - custom-action
+  - javascript
+  - toolkit
+patterns:
+  - regex: 'ERR_REQUIRE_ESM'
+    flags: 'i'
+  - regex: 'No "exports" main defined in @actions/core'
+    flags: 'i'
+  - regex: 'require\(\) of ES Module.*@actions/core'
+    flags: 'i'
+  - regex: 'Must use import to load ES Module'
+    flags: 'i'
+error_messages:
+  - 'Error [ERR_REQUIRE_ESM]: require() of ES Module .../node_modules/@actions/core/lib/core.js not supported'
+  - 'No "exports" main defined in @actions/core/package.json @v3'
+  - 'Must use import to load ES Module: .../node_modules/@actions/core/lib/core.js'
+root_cause: |
+  @actions/core version 3.0.0 (published January 29, 2026) converted the package from CommonJS
+  to ESM-only. Before v3, the package shipped as CommonJS and was consumable with:
+
+    const core = require('@actions/core');
+
+  With v3.0.0 and later, the package is ESM-only. CommonJS callers that use require() receive
+  one of these errors at runtime:
+
+    - ERR_REQUIRE_ESM: Node.js refuses to require() an ES module
+    - "No 'exports' main defined in @actions/core/package.json @v3" — the ESM package.json
+      exports map does not expose a CommonJS entry point
+
+  This affects any custom JavaScript or TypeScript action that:
+  1. Uses require('@actions/core') — e.g., const core = require('@actions/core');
+  2. Uses TypeScript compiled to CommonJS (the default 'module': 'commonjs' in tsconfig.json)
+     even when source code uses import syntax — the compiled output uses require() calls
+  3. Bundles with webpack/ncc in CommonJS mode without transpiling the ESM dependency
+
+  The actions/typescript-action template and thousands of published community actions that
+  were written for @actions/core v1–v2 are affected when their dependencies are updated.
+
+  Note: This is a Node.js runtime error — the workflow definition is valid YAML. The failure
+  appears in the step log when Node.js tries to load the bundled action.
+fix: |
+  There are two approaches depending on whether you control the action source code:
+
+  Option A — Migrate the action to ESM (recommended for new actions):
+  Update the action's package.json to "type": "module", convert all require() calls to
+  import statements, and recompile/rebundle. Use "module": "ESNext" or "module": "NodeNext"
+  in tsconfig.json for TypeScript actions.
+
+  Option B — Pin @actions/core to v2.x (quick fix for existing actions):
+  Pin to the last CommonJS-compatible version: @actions/core@^2.0.3 in package.json.
+  This avoids the ESM migration but misses v3 improvements (new APIs, performance).
+
+  For third-party community actions you don't control: check if the action maintainer has
+  published an updated version. If not, pin the action to the last working version tag
+  (before they upgraded to @actions/core v3).
+fix_code:
+  - language: yaml
+    label: 'Pin @actions/core to v2 in package.json (quick fix for existing CommonJS actions)'
+    code: |
+      # In the action's package.json, pin to v2 (last CommonJS-compatible release)
+      # {
+      #   "dependencies": {
+      #     "@actions/core": "^2.0.3"
+      #   }
+      # }
+      jobs:
+        build-action:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: actions/setup-node@v4
+              with:
+                node-version: '20'
+
+            - name: Install pinned dependencies
+              run: npm ci
+
+            - name: Bundle action
+              run: npm run build
+
+  - language: yaml
+    label: 'Migrate action to ESM — update tsconfig and entry point for @actions/core v3'
+    code: |
+      # tsconfig.json for ESM TypeScript action:
+      # {
+      #   "compilerOptions": {
+      #     "module": "NodeNext",
+      #     "moduleResolution": "NodeNext",
+      #     "target": "ES2020"
+      #   }
+      # }
+      #
+      # package.json:
+      # {
+      #   "type": "module",
+      #   "dependencies": { "@actions/core": "^3.0.0" }
+      # }
+      #
+      # In source, use ESM imports (not require):
+      # import * as core from '@actions/core';
+      jobs:
+        build-esm-action:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-node@v4
+              with:
+                node-version: '20'
+            - name: Build ESM action
+              run: npm ci && npm run build
+prevention:
+  - 'Always check the @actions/core RELEASES.md when upgrading — v3.0.0 is an ESM-only breaking change requiring migration'
+  - 'TypeScript actions compiled with "module": "commonjs" in tsconfig.json will produce require() calls even if source uses import — set "module": "NodeNext" for ESM compatibility'
+  - 'Use Dependabot or Renovate with a major version constraint so @actions/core upgrades are reviewed before merging'
+  - 'Bundle your action with ncc using --esm flag or use esbuild with format=esm to produce ESM-compatible bundles'
+  - 'Test bundled actions locally with node dist/index.js before publishing to catch ERR_REQUIRE_ESM before CI fails'
+docs:
+  - url: 'https://github.com/actions/toolkit/blob/main/packages/core/RELEASES.md'
+    label: '@actions/core RELEASES.md — v3.0.0 ESM-only breaking change'
+  - url: 'https://github.com/actions/toolkit/issues/2294'
+    label: 'actions/toolkit #2294 — No "exports" main defined in @actions/core/package.json @v3 (8 reactions)'
+  - url: 'https://github.com/actions/toolkit/issues/2287'
+    label: 'actions/toolkit #2287 — Outdated require() docs for ESM packages (5 reactions)'
+  - url: 'https://github.com/actions/typescript-action/issues/1165'
+    label: 'actions/typescript-action #1165 — Example for @actions/core >= 3 migration'
+  - url: 'https://nodejs.org/api/esm.html#interoperability-with-commonjs'
+    label: 'Node.js docs — ESM/CommonJS interoperability'

package/errors/runner-environment/arm64-runner-binary-exec-format-error.yml

@@ -0,0 +1,100 @@
+id: runner-environment-133
+title: 'ARM64 runners: downloaded x86_64 binary fails with "Exec format error" — wrong architecture'
+category: runner-environment
+severity: error
+tags:
+  - arm64
+  - aarch64
+  - binary
+  - exec-format-error
+  - ubuntu-arm
+  - architecture
+patterns:
+  - regex: 'cannot execute binary file: Exec format error'
+    flags: 'i'
+  - regex: 'Exec format error'
+    flags: 'i'
+  - regex: 'exec.*format error'
+    flags: 'i'
+error_messages:
+  - './my-tool: cannot execute binary file: Exec format error'
+  - '/usr/local/bin/kubectl: cannot execute binary file: Exec format error'
+  - 'bash: ./tool: cannot execute binary file: Exec format error'
+root_cause: |
+  GitHub-hosted ubuntu-24.04-arm and ubuntu-22.04-arm runners use ARM64 (aarch64) CPUs.
+  The RUNNER_ARCH environment variable returns ARM64 on these runners, not X64.
+
+  Workflows that download pre-built binaries using hardcoded architecture suffixes like
+  linux-amd64, linux-x86_64, or linux-x64 download x86_64 binaries that cannot execute on
+  ARM64 hardware. The Linux kernel rejects the binary with "Exec format error" (ENOEXEC)
+  because the ELF architecture header in the binary does not match the host CPU.
+
+  Common patterns that break:
+  - Hardcoded URL: https://example.com/tool-linux-amd64.tar.gz
+  - Shell variable set once: ARCH="amd64" without checking RUNNER_ARCH
+  - Workflow matrix that includes ubuntu-24.04-arm without updating download URLs
+  - Third-party scripts that assume x86_64 without ARM64 support
+
+  This is a silent-ish failure — the binary downloads successfully (HTTP 200), extracts
+  without error, but fails only when executed.
+fix: |
+  Use the RUNNER_ARCH environment variable or uname -m to detect architecture and select
+  the correct binary:
+
+  - RUNNER_ARCH is X64 on x86_64 runners, ARM64 on ARM64 runners
+  - uname -m returns x86_64 on x86_64, aarch64 on ARM64
+
+  Normalize to the convention used by the tool's release naming (amd64/arm64 or x86_64/aarch64).
+  Where possible, prefer using setup-* actions that handle multi-architecture automatically.
+fix_code:
+  - language: yaml
+    label: 'Detect architecture and download correct binary'
+    code: |
+      jobs:
+        install-tool:
+          runs-on: ${{ matrix.runner }}
+          strategy:
+            matrix:
+              runner: [ubuntu-24.04, ubuntu-24.04-arm]
+          steps:
+            - name: Detect architecture and download tool
+              run: |
+                ARCH=$(uname -m)
+                case "$ARCH" in
+                  x86_64)  DL_ARCH="amd64" ;;
+                  aarch64) DL_ARCH="arm64" ;;
+                  *) echo "Unsupported arch: $ARCH"; exit 1 ;;
+                esac
+                curl -sSL "https://example.com/tool-linux-${DL_ARCH}.tar.gz" | tar xz
+                sudo mv tool /usr/local/bin/
+
+  - language: yaml
+    label: 'Use RUNNER_ARCH environment variable (GitHub-native)'
+    code: |
+      jobs:
+        install-tool:
+          runs-on: ubuntu-24.04-arm
+          steps:
+            - name: Install tool using RUNNER_ARCH
+              run: |
+                # RUNNER_ARCH is X64 or ARM64 (uppercase)
+                if [ "$RUNNER_ARCH" = "ARM64" ]; then
+                  DL_ARCH="arm64"
+                else
+                  DL_ARCH="amd64"
+                fi
+                curl -sSL "https://releases.example.com/tool-linux-${DL_ARCH}" -o /usr/local/bin/tool
+                chmod +x /usr/local/bin/tool
+prevention:
+  - 'Never hardcode linux-amd64 or linux-x86_64 in binary download URLs — always parameterize by architecture'
+  - 'Prefer setup-* GitHub Actions (setup-node, setup-go, setup-java) over manual binary downloads — they handle ARM64 automatically'
+  - 'Add ubuntu-24.04-arm to your test matrix to catch architecture issues before they affect users'
+  - 'Check tool release pages for ARM64 availability before migrating to ARM64 runners — not all tools provide arm64 builds'
+  - 'Use RUNNER_ARCH (GitHub variable) or uname -m (portable) to detect architecture in shell scripts'
+docs:
+  - url: 'https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources'
+    label: 'GitHub-hosted runners — supported runner types including ARM64'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables'
+    label: 'Default environment variables — RUNNER_ARCH values'
+  - url: 'https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-ARM64-Readme.md'
+    label: 'ubuntu-24.04-arm runner software report'

package/errors/runner-environment/ubuntu-24-no-swap-oom-exit-137.yml

@@ -0,0 +1,124 @@
+id: runner-environment-135
+title: 'ubuntu-24.04: no swap memory — memory-intensive builds killed with exit code 137 (OOM)'
+category: runner-environment
+severity: error
+tags:
+  - oom
+  - memory
+  - swap
+  - ubuntu-24
+  - exit-137
+  - killed
+patterns:
+  - regex: 'Error 137'
+    flags: 'i'
+  - regex: 'exit code 137'
+    flags: 'i'
+  - regex: '^Killed\s*$'
+    flags: 'm'
+  - regex: 'out of memory|OOM|oom.killer'
+    flags: 'i'
+error_messages:
+  - 'make: *** [Makefile:42: build] Error 137'
+  - 'Killed'
+  - 'Process exited with code 137'
+  - 'error Command failed with exit code 137'
+  - 'npm ERR! code 137'
+root_cause: |
+  GitHub-hosted ubuntu-24.04 runners provide approximately 29GB RAM but have no swap space.
+  Ubuntu 22.04 runners provided about 6GB of swap as overflow capacity. When a job exhausts
+  physical RAM, the Linux OOM killer terminates the offending process with SIGKILL (signal 9),
+  producing exit code 137 (128 + 9).
+
+  The killed process may be:
+  - Node.js during webpack/esbuild/rollup bundle generation for large frontend projects
+  - Gradle during Android AAB/APK build or large multi-module Java projects
+  - Electron Forge/Builder packaging step
+  - C/C++ linker (ld) linking large binaries with many object files
+  - Cargo (Rust) compiling with high parallelism or many dependencies
+
+  The failure is often hard to diagnose because:
+  - No explicit "Out of Memory" message appears in the workflow log
+  - The step log simply shows "Killed" and exit code 137
+  - The runner does not report memory usage in the workflow summary
+
+  If the same workflow runs on ubuntu-22.04 without issues, missing swap is the likely cause.
+fix: |
+  Option A — Add a swap file manually before the memory-intensive step. This adds ~30 seconds
+  to job setup but provides 8GB of overflow capacity:
+
+  Option B — Reduce peak memory usage:
+  - Node.js: pass --max-old-space-size=N (MB) to node or set NODE_OPTIONS env var
+  - Gradle: reduce org.gradle.jvmargs heap in gradle.properties
+  - Cargo: set CARGO_BUILD_JOBS=2 to reduce parallel compilation
+  - webpack: use --parallel false or reduce splitChunks settings
+
+  Option C — Use a larger GitHub-hosted runner with more RAM (requires paid plan):
+  ubuntu-24.04 with 64GB RAM is available as a larger runner.
+fix_code:
+  - language: yaml
+    label: 'Add 8GB swap file before memory-intensive build step'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Add swap space
+              run: |
+                sudo fallocate -l 8G /swapfile
+                sudo chmod 600 /swapfile
+                sudo mkswap /swapfile
+                sudo swapon /swapfile
+                swapon --show
+                free -h
+
+            - name: Build (memory-intensive)
+              run: npm run build
+
+  - language: yaml
+    label: 'Reduce Node.js memory usage with --max-old-space-size'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-24.04
+          env:
+            NODE_OPTIONS: '--max-old-space-size=6144'
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-node@v4
+              with:
+                node-version: '20'
+            - run: npm ci
+            - run: npm run build
+
+  - language: yaml
+    label: 'Reduce Gradle heap for Android/Java builds'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Set Gradle memory limits
+              run: |
+                mkdir -p ~/.gradle
+                echo 'org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=512m' >> ~/.gradle/gradle.properties
+
+            - name: Build APK
+              run: ./gradlew assembleRelease
+prevention:
+  - 'Test builds on ubuntu-24.04 explicitly — do not assume ubuntu-22.04 memory behavior transfers'
+  - 'Add a swap file as a build step when migrating large builds to ubuntu-24.04'
+  - 'Set NODE_OPTIONS=--max-old-space-size as a job-level env var for Node.js heavy workflows'
+  - 'Monitor build memory usage locally: /usr/bin/time -v npm run build shows peak RSS'
+  - 'Exit code 137 with no explicit error is the canonical indicator of OOM kill — add this as a diagnostic check'
+docs:
+  - url: 'https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources'
+    label: 'GitHub-hosted runner hardware specs — RAM and storage per runner type'
+  - url: 'https://github.com/actions/runner-images/issues'
+    label: 'runner-images issues — search "OOM" or "exit 137" for community reports'
+  - url: 'https://nodejs.org/api/cli.html#--max-old-space-sizesize-in-megabytes'
+    label: 'Node.js CLI docs — --max-old-space-size option'

package/errors/runner-environment/ubuntu-24-openjdk11-no-installation-candidate.yml

@@ -0,0 +1,99 @@
+id: runner-environment-134
+title: 'ubuntu-24.04: openjdk-11-jdk has no installation candidate — Java 11 removed from Ubuntu 24 repos'
+category: runner-environment
+severity: error
+tags:
+  - java
+  - openjdk
+  - ubuntu-24
+  - apt
+  - java-11
+  - noble
+patterns:
+  - regex: 'Package .openjdk-11.*has no installation candidate'
+    flags: 'i'
+  - regex: 'openjdk-11-jdk.*no installation candidate'
+    flags: 'i'
+  - regex: 'E: Package .openjdk-11'
+    flags: 'i'
+error_messages:
+  - 'E: Package ''openjdk-11-jdk'' has no installation candidate'
+  - 'E: Package ''openjdk-11-jre'' has no installation candidate'
+  - 'E: Unable to locate package openjdk-11-jdk'
+root_cause: |
+  Ubuntu 24.04 LTS (Noble Numbat) dropped OpenJDK 11 from its official package repositories.
+  The minimum available Java version via apt on Ubuntu 24.04 is OpenJDK 17 (openjdk-17-jdk)
+  along with OpenJDK 21 (openjdk-21-jdk). OpenJDK 11 packages that existed in Ubuntu 22.04
+  (Jammy) are not present in Ubuntu 24.04 (Noble) main or universe repos.
+
+  Workflows that install Java via apt-get will fail:
+    sudo apt-get install -y openjdk-11-jdk  # Fails on ubuntu-24.04
+    sudo apt-get install -y openjdk-11-jre  # Fails on ubuntu-24.04
+
+  This affects workflows that:
+  - Directly install OpenJDK via apt without using actions/setup-java
+  - Use Docker images based on ubuntu:24.04 inside workflow steps
+  - Run scripts that call apt-get install openjdk-11* expecting Ubuntu 22 behavior
+
+  Note: Java 11 is still supported under long-term support plans but must be obtained from
+  third-party sources (Adoptium/Temurin, Amazon Corretto, Azul Zulu) rather than Ubuntu repos.
+fix: |
+  Use actions/setup-java to install any Java version including 11. The action downloads from
+  a distribution vendor (Temurin, Corretto, Zulu, etc.) rather than Ubuntu packages, making
+  it distribution-independent and supporting Java 11 on ubuntu-24.04.
+
+  Never use apt-get to install Java on GitHub-hosted runners — always use actions/setup-java
+  which handles version discovery, caching, JAVA_HOME configuration, and multi-platform support.
+fix_code:
+  - language: yaml
+    label: 'Use actions/setup-java to install Java 11 (works on ubuntu-24.04)'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-24.04
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: actions/setup-java@v4
+              with:
+                java-version: '11'
+                distribution: 'temurin'
+                cache: 'maven'
+
+            - name: Build with Maven
+              run: mvn -B package --file pom.xml
+
+  - language: yaml
+    label: 'Multi-version Java matrix — test across Java 11, 17, 21'
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-24.04
+          strategy:
+            matrix:
+              java-version: ['11', '17', '21']
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: actions/setup-java@v4
+              with:
+                java-version: ${{ matrix.java-version }}
+                distribution: 'temurin'
+
+            - name: Run tests
+              run: mvn test
+prevention:
+  - 'Always use actions/setup-java to install Java on GitHub-hosted runners — never rely on apt-get for Java'
+  - 'Pin the Java distribution explicitly (temurin, corretto, zulu) to avoid resolution differences across Ubuntu versions'
+  - 'Test workflows on ubuntu-24.04 explicitly when migrating from ubuntu-22.04 or ubuntu-20.04'
+  - 'Check Ubuntu package availability with https://packages.ubuntu.com before relying on apt for any tool installation'
+  - 'Validate Java availability in your workflow with: java -version && javac -version as an early smoke check'
+docs:
+  - url: 'https://github.com/actions/setup-java'
+    label: 'actions/setup-java — install Java on any GitHub-hosted runner'
+  - url: 'https://packages.ubuntu.com/noble/'
+    label: 'Ubuntu 24.04 (Noble) package search — verify available package versions'
+  - url: 'https://adoptium.net/temurin/releases/?version=11'
+    label: 'Eclipse Temurin — Java 11 LTS builds for all platforms'
+  - url: 'https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md'
+    label: 'ubuntu-24.04 runner software report — pre-installed Java versions'

package/errors/runner-environment/windows-2025-dotnet6-sdk-removed.yml

@@ -0,0 +1,96 @@
+id: runner-environment-132
+title: 'windows-2025 runner: .NET 6 SDK removed — NETSDK1045 when targeting net6.0'
+category: runner-environment
+severity: error
+tags:
+  - dotnet
+  - windows-2025
+  - net6
+  - sdk
+  - netsdk1045
+  - eol
+patterns:
+  - regex: 'NETSDK1045.*\.NET 6\.0'
+    flags: 'i'
+  - regex: 'does not support targeting.*\.NET 6'
+    flags: 'i'
+  - regex: 'error NETSDK1045'
+    flags: 'i'
+error_messages:
+  - 'error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0.'
+  - 'error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0. Either target .NET 8.0 or higher, or use a .NET SDK that supports .NET 6.0.'
+root_cause: |
+  .NET 6 reached end-of-life on November 12, 2024. The windows-2025 runner image does not
+  include the .NET 6 SDK or runtime. Pre-installed .NET SDKs on windows-2025 are .NET 8
+  and .NET 9 only.
+
+  Workflows using dotnet build, dotnet test, or dotnet publish that target net6.0 TFM fail
+  with NETSDK1045 because no installed SDK can build or run .NET 6 targets. This affects:
+  - Projects with <TargetFramework>net6.0</TargetFramework> in their .csproj
+  - Multi-target projects including net6.0 in <TargetFrameworks>
+  - Workflows that run dotnet run with a net6.0 project
+
+  The windows-2022 runner still includes .NET 6 for legacy compatibility, so workflows using
+  runs-on: windows-2022 are unaffected. The breakage appears when migrating to windows-2025
+  or when windows-latest switches to windows-2025.
+fix: |
+  Option A (recommended): Upgrade the project's TargetFramework to net8.0 or net9.0. .NET 8
+  is the current LTS release and is pre-installed on windows-2025.
+
+  Option B (legacy support): Use actions/setup-dotnet to explicitly install the .NET 6 SDK.
+  Note: .NET 6 is EOL and receives no security patches — this option is not recommended for
+  production workloads.
+
+  Option C (short-term): Pin to windows-2022 runner temporarily while upgrading.
+fix_code:
+  - language: yaml
+    label: 'Option A — upgrade target framework to .NET 8 LTS (recommended)'
+    code: |
+      # In your .csproj, update:
+      # <TargetFramework>net8.0</TargetFramework>
+      # Then in your workflow:
+      jobs:
+        build:
+          runs-on: windows-2025
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: actions/setup-dotnet@v4
+              with:
+                dotnet-version: '8.0.x'
+
+            - name: Build
+              run: dotnet build --configuration Release
+
+  - language: yaml
+    label: 'Option B — explicitly install .NET 6 SDK (EOL, not recommended for production)'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-2025
+          steps:
+            - uses: actions/checkout@v4
+
+            - uses: actions/setup-dotnet@v4
+              with:
+                dotnet-version: |
+                  6.0.x
+                  8.0.x
+
+            - name: Build
+              run: dotnet build --framework net6.0
+prevention:
+  - 'Audit all TargetFramework and TargetFrameworks values before migrating to windows-2025'
+  - 'Monitor the .NET release lifecycle at https://dotnet.microsoft.com/platform/support/policy for upcoming EOL dates'
+  - 'Use Dependabot or Renovate to track .NET SDK versions referenced in global.json or setup-dotnet steps'
+  - 'Check the windows-2025 runner software report (runner-images/Windows2025-Readme.md) before migration to see pre-installed SDKs'
+  - 'Set up a CI matrix that tests both windows-2022 and windows-2025 during migration periods'
+docs:
+  - url: 'https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md'
+    label: 'windows-2025 runner software report — pre-installed SDK versions'
+  - url: 'https://dotnet.microsoft.com/platform/support/policy/dotnet-core'
+    label: '.NET release lifecycle and EOL schedule'
+  - url: 'https://github.com/actions/setup-dotnet'
+    label: 'actions/setup-dotnet — install specific .NET SDK versions'
+  - url: 'https://github.com/actions/runner-images/discussions'
+    label: 'GitHub runner-images discussions — windows-2025 migration issues'

package/errors/yaml-syntax/schedule-timezone-actionlint-unknown-key.yml

@@ -0,0 +1,135 @@
+id: yaml-syntax-046
+title: 'on.schedule timezone field causes actionlint and third-party parsers to report "expected cron key" syntax error'
+category: yaml-syntax
+severity: warning
+tags:
+  - schedule
+  - cron
+  - timezone
+  - actionlint
+  - linting
+  - scorecard-action
+patterns:
+  - regex: 'expected "cron" key for element of "schedule" section but got "timezone"'
+    flags: 'i'
+  - regex: 'unable to parse github workflow.*timezone'
+    flags: 'i'
+  - regex: 'workflow verification failed.*timezone.*syntax-check'
+    flags: 'i'
+  - regex: '\[syntax-check\].*timezone'
+    flags: 'i'
+error_messages:
+  - 'expected "cron" key for element of "schedule" section but got "timezone" [syntax-check]'
+  - 'error sending scorecard results to webapp: http response 400, status: 400 Bad Request, error: {"code":400,"message":"workflow verification failed: unable to parse github workflow: [:9:7: expected \"cron\" key for element of \"schedule\" section but got \"timezone\" [syntax-check]]"}'
+  - 'on.schedule[0]: unexpected key "timezone"'
+root_cause: |
+  GitHub Actions added IANA timezone support for scheduled workflows in March 2026
+  (announced in the Late March 2026 changelog). The new syntax allows specifying a timezone
+  alongside the cron expression:
+
+    on:
+      schedule:
+        - cron: '30 5 * * 1-5'
+          timezone: "America/New_York"
+
+  However, this feature was not immediately recognized by external workflow-parsing tools:
+
+  1. **actionlint** — The widely-used GitHub Actions linting tool (used in many CI pipelines
+     as a pre-commit or CI check) did not support the timezone key until version 0.7.4
+     (released March 30, 2026). Earlier versions report the error:
+       expected "cron" key for element of "schedule" section but got "timezone" [syntax-check]
+     This causes actionlint-based CI checks to fail even though the workflow is valid.
+
+  2. **ossf/scorecard-action** — The OpenSSF Scorecard action verifies workflow structure
+     using an internal parser that did not recognize the timezone key. When scorecard-action
+     runs on a workflow that contains `timezone:`, it returns HTTP 400 from the Scorecard API:
+       workflow verification failed: unable to parse github workflow: [...timezone [syntax-check]]
+     This causes the scorecard CI job to fail on otherwise-valid workflows.
+
+  3. **GitHub VS Code extension** — The vscode-github-actions extension (v0.29.1 and earlier)
+     marks timezone as an "unexpected value" in the schema validation overlay, producing
+     squiggly underlines even though the workflow runs correctly.
+
+  The root issue is that the new timezone key was added to GitHub's workflow syntax faster
+  than third-party tooling could update their schema definitions.
+fix: |
+  Upgrade the affected tools to versions that support the timezone key:
+
+  1. **actionlint**: Upgrade to version 0.7.4 or later. Pin the actionlint version in your
+     CI workflow to avoid surprise failures on future schema changes.
+
+  2. **ossf/scorecard-action**: Upgrade to the latest version. The Scorecard API was updated
+     to recognize the timezone key. If you cannot upgrade, temporarily remove the timezone
+     field from your schedule — or use the @latest tag to stay on the most recent release.
+
+  3. **GitHub VS Code extension**: Upgrade to the latest version from the VS Code marketplace.
+     The false-positive schema warning has no runtime effect and does not affect workflow
+     execution.
+
+  If you are blocked from upgrading tools (e.g., in a corporate environment), you can work
+  around the linting error by keeping the cron in UTC and removing the timezone field,
+  adjusting the cron expression offset manually for the desired local time.
+fix_code:
+  - language: yaml
+    label: 'Pin actionlint to v0.7.4+ in CI to support the timezone key'
+    code: |
+      jobs:
+        lint:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Pin actionlint to v0.7.4+ which supports timezone in on.schedule
+            - name: Lint GitHub Actions workflows
+              uses: rhysd/actionlint@v0.7.4
+              with:
+                shellcheck: 'false'
+
+  - language: yaml
+    label: 'Valid on.schedule with timezone (requires actionlint 0.7.4+ and updated scorecard-action)'
+    code: |
+      on:
+        schedule:
+          # Run at 9 AM Eastern (UTC-5 in winter, UTC-4 in summer)
+          # With timezone support: specify local time directly
+          - cron: '0 9 * * 1-5'
+            timezone: "America/New_York"
+
+      jobs:
+        scheduled-job:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: echo "Running at 9 AM Eastern"
+
+  - language: yaml
+    label: 'Workaround — use UTC offset in cron expression (no timezone key, works with all tool versions)'
+    code: |
+      on:
+        schedule:
+          # 9 AM Eastern Standard Time = 14:00 UTC (winter)
+          # Adjust manually for DST when needed
+          - cron: '0 14 * * 1-5'
+
+      jobs:
+        scheduled-job:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: echo "Running at approximately 9 AM Eastern"
+prevention:
+  - 'When adopting new GitHub Actions syntax features, check that your CI linting tools (actionlint, mega-linter, super-linter) support the new key before adding it to workflows'
+  - 'Pin actionlint to a specific version in CI and bump intentionally — use rhysd/actionlint@v0.7.4 or later for timezone support'
+  - 'The vscode-github-actions extension schema squiggly-underline for "timezone" is cosmetic only — the workflow runs correctly on GitHub regardless'
+  - 'If using ossf/scorecard-action, always pin to a tagged release rather than @main to avoid unexpected parser failures from scorecard API schema changes'
+docs:
+  - url: 'https://github.blog/changelog/2026-03-19-github-actions-late-march-2026-updates/#github-actions-timezone-support-for-scheduled-workflows'
+    label: 'GitHub Changelog: Timezone support for scheduled workflows (March 2026)'
+  - url: 'https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onschedule'
+    label: 'GitHub Docs: on.schedule syntax including timezone field'
+  - url: 'https://github.com/rhysd/actionlint/issues/638'
+    label: 'actionlint #638 — Add support for timezone for schedule triggers (13 reactions, fixed in 0.7.4)'
+  - url: 'https://github.com/ossf/scorecard-action/issues/1645'
+    label: 'scorecard-action #1645 — Upload fails if schedule:timezone is used in a workflow'
+  - url: 'https://github.com/github/vscode-github-actions/issues/577'
+    label: 'vscode-github-actions #577 — schedule timezone marked as unknown in VS Code extension'

package/package.json

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