@htekdev/actions-debugger 1.0.58 → 1.0.60

package/errors/permissions-auth/github-token-cross-repo-dispatch-limitation.yml

@@ -0,0 +1,115 @@
+id: permissions-auth-043
+title: 'GITHUB_TOKEN cannot dispatch workflows or events in other repositories'
+category: permissions-auth
+severity: error
+tags:
+  - GITHUB_TOKEN
+  - repository_dispatch
+  - workflow_dispatch
+  - cross-repo
+  - 404
+  - permissions
+patterns:
+  - regex: 'Resource not accessible by integration'
+    flags: 'i'
+  - regex: '404.*dispatches|dispatches.*404'
+    flags: 'i'
+  - regex: 'HttpError: Not Found'
+    flags: 'i'
+error_messages:
+  - 'Resource not accessible by integration'
+  - 'HttpError: Not Found'
+  - '{"message":"Not Found","documentation_url":"https://docs.github.com/rest/repos/repos#create-a-repository-dispatch-event"}'
+  - 'RequestError [HttpError]: Not Found'
+root_cause: |
+  GITHUB_TOKEN is automatically scoped to the repository where the workflow
+  runs. It cannot authenticate to any other repository, regardless of what is
+  declared in the workflow's permissions block. The permissions block controls
+  only the scopes of the automatically-generated token for the CURRENT repo —
+  it has no effect on access to other repositories.
+
+  Attempts to call the GitHub REST API against a different repository —
+  including POST /repos/{owner}/{other-repo}/dispatches (repository_dispatch)
+  or POST /repos/{owner}/{other-repo}/actions/workflows/{id}/dispatches
+  (workflow_dispatch) — return 404 Not Found. GitHub returns 404 rather than
+  403 to avoid leaking information about whether the target repository exists
+  or is private.
+
+  This is a hard authentication boundary enforced by GitHub's token system,
+  not a configuration issue. No amount of permissions: adjustments in the
+  workflow file can grant the automatic GITHUB_TOKEN cross-repository access.
+
+  Note: this is distinct from the GITHUB_TOKEN loopback limitation (where
+  GITHUB_TOKEN cannot trigger new workflow runs in the SAME repository). This
+  error applies to any cross-repository API call.
+fix: |
+  Replace GITHUB_TOKEN with a credential that has access to the target
+  repository: a Personal Access Token (PAT) with repo scope, or a GitHub App
+  installation token scoped to both repositories. Store the credential as an
+  encrypted repository or organization secret.
+
+  GitHub Apps with installation tokens are the recommended approach for
+  production cross-repo automation — they provide fine-grained permissions,
+  do not depend on a specific user account, and tokens are automatically
+  rotated.
+fix_code:
+  - language: yaml
+    label: 'Use a PAT secret for cross-repo repository_dispatch'
+    code: |
+      jobs:
+        trigger-downstream:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Dispatch event to other repository
+              uses: actions/github-script@v7
+              with:
+                github-token: ${{ secrets.CROSS_REPO_PAT }}
+                script: |
+                  await github.rest.repos.createDispatchEvent({
+                    owner: 'my-org',
+                    repo: 'other-repo',
+                    event_type: 'build-triggered',
+                    client_payload: {
+                      ref: context.ref,
+                      sha: context.sha
+                    }
+                  });
+  - language: yaml
+    label: 'Use a GitHub App installation token for cross-repo workflow dispatch (recommended)'
+    code: |
+      jobs:
+        trigger-downstream:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Generate GitHub App installation token
+              id: app-token
+              uses: actions/create-github-app-token@v1
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+                owner: my-org
+                repositories: other-repo
+
+            - name: Dispatch workflow in other repository
+              uses: actions/github-script@v7
+              with:
+                github-token: ${{ steps.app-token.outputs.token }}
+                script: |
+                  await github.rest.actions.createWorkflowDispatch({
+                    owner: 'my-org',
+                    repo: 'other-repo',
+                    workflow_id: 'deploy.yml',
+                    ref: 'main'
+                  });
+prevention:
+  - 'Never use ${{ secrets.GITHUB_TOKEN }} in API calls targeting other repositories — it will always 404'
+  - 'Prefer GitHub Apps with installation tokens over PATs for cross-repo automation — scoped, auto-rotating, and not tied to a user account'
+  - 'Store cross-repo PATs as organization secrets so they are reusable across multiple source repositories without per-repo duplication'
+  - 'When debugging 404 on dispatch endpoints, first check whether the token is GITHUB_TOKEN vs a PAT — this is the most common cause'
+docs:
+  - url: 'https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token'
+    label: 'GitHub Docs: Permissions for the GITHUB_TOKEN'
+  - url: 'https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow'
+    label: 'GitHub Docs: Authenticating with a GitHub App in GitHub Actions'
+  - url: 'https://github.com/orgs/community/discussions/26724'
+    label: 'GitHub Community: GITHUB_TOKEN cannot dispatch to another repository'

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/reusable-workflow-outputs-undeclared-workflow-level.yml

@@ -0,0 +1,95 @@
+id: silent-failures-060
+title: 'Reusable workflow outputs not declared at on.workflow_call.outputs are silently empty in callers'
+category: silent-failures
+severity: silent-failure
+tags:
+  - reusable-workflow
+  - workflow_call
+  - outputs
+  - empty-string
+  - silent-failure
+patterns:
+  - regex: 'needs\.[a-z][a-z0-9_-]*\.outputs\.[a-z][a-z0-9_-]*'
+    flags: 'i'
+error_messages:
+  - '(no error emitted — callers receive empty strings silently)'
+  - 'Error: Input required and not supplied'
+root_cause: |
+  Reusable workflows require a two-level output declaration. Developers
+  correctly declare job-level outputs under jobs.<job-id>.outputs, but omit
+  the second required declaration: the workflow-level outputs block under
+  on.workflow_call.outputs.
+
+  Without the workflow-level outputs declaration, any caller that references
+  ${{ needs.<call-job>.outputs.<name> }} receives an empty string. GitHub
+  Actions does not emit any error, warning, or annotation — downstream steps
+  silently receive empty values, producing wrong behavior or spurious failures
+  (e.g., artifact path is empty, deployment target is blank).
+
+  The root cause is that GitHub's reusable workflow output model requires two
+  separate declarations:
+    1. job.outputs: maps a step output to a job-scoped output
+    2. on.workflow_call.outputs: hoists a job output up to the workflow level
+       so external callers can reference it
+
+  Omitting level 2 is invisible — the job output exists internally but is
+  never exposed to the calling workflow.
+fix: |
+  Add an outputs block directly under on.workflow_call that maps each desired
+  workflow output name to ${{ jobs.<job-id>.outputs.<output-name> }}. This is
+  in addition to (not a replacement for) the job-level outputs block.
+fix_code:
+  - language: yaml
+    label: 'Reusable workflow: declare outputs at both job level and on.workflow_call level'
+    code: |
+      on:
+        workflow_call:
+          outputs:
+            build-version:
+              description: 'The semantic version produced by this workflow'
+              value: ${{ jobs.build.outputs.build-version }}
+            artifact-path:
+              description: 'Path to the uploaded artifact'
+              value: ${{ jobs.build.outputs.artifact-path }}
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          outputs:
+            build-version: ${{ steps.version.outputs.version }}
+            artifact-path: ${{ steps.upload.outputs.artifact-path }}
+          steps:
+            - id: version
+              run: echo "version=1.2.3" >> "$GITHUB_OUTPUT"
+              shell: bash
+            - id: upload
+              uses: actions/upload-artifact@v4
+              with:
+                name: my-artifact
+                path: dist/
+  - language: yaml
+    label: 'Calling workflow: access reusable workflow outputs via needs context'
+    code: |
+      jobs:
+        call-build:
+          uses: ./.github/workflows/build.yml
+
+        deploy:
+          needs: call-build
+          runs-on: ubuntu-latest
+          steps:
+            - name: Use build outputs
+              run: |
+                echo "Version: ${{ needs.call-build.outputs.build-version }}"
+                echo "Artifact: ${{ needs.call-build.outputs.artifact-path }}"
+              shell: bash
+prevention:
+  - 'Always declare outputs under on.workflow_call.outputs in addition to any job-level outputs blocks — they are two distinct YAML nodes'
+  - 'Immediately echo needs.<call-job>.outputs.* in the caller after wiring up to verify outputs are populated during development'
+  - 'Use actionlint locally or in CI to catch missing workflow-level output declarations before they ship'
+  - 'Treat the two-level declaration as a checklist: job outputs block + workflow_call outputs block'
+docs:
+  - url: 'https://docs.github.com/en/actions/sharing-automations/reusing-workflows#using-outputs-from-a-reusable-workflow'
+    label: 'GitHub Docs: Using outputs from a reusable workflow'
+  - url: 'https://github.com/orgs/community/discussions/17245'
+    label: 'GitHub Community: Outputs from reusable workflow missing in caller'

package/errors/triggers/pull-request-target-checkout-base-branch.yml

@@ -0,0 +1,101 @@
+id: triggers-044
+title: 'pull_request_target checks out base branch by default — PR head requires explicit ref'
+category: triggers
+severity: silent-failure
+tags:
+  - pull_request_target
+  - checkout
+  - ref
+  - base-branch
+  - security
+  - fork
+patterns:
+  - regex: 'on:\s*\n\s*pull_request_target'
+    flags: 'im'
+  - regex: 'uses:\s*actions/checkout.*\n(?!.*ref:)'
+    flags: 'im'
+error_messages:
+  - '(no error — workflow runs against base branch code, not PR changes)'
+root_cause: |
+  pull_request_target runs in the context of the BASE repository rather than
+  the contributor's fork. This is an intentional security boundary: because
+  the workflow has access to repository secrets and typically runs with write
+  permissions, GitHub executes it against trusted code on the base branch
+  rather than potentially untrusted PR code.
+
+  As a direct consequence, actions/checkout without an explicit ref: parameter
+  checks out the TARGET BRANCH (e.g., main), not the contributor's changes.
+  The workflow appears to run successfully — tests pass, linters pass — but
+  only because they are testing the existing base branch code. The PR's actual
+  changes are completely ignored. CI gives a false green for every PR
+  regardless of what was submitted.
+
+  This is among the most common misuses of pull_request_target, appearing
+  frequently in workflows that were migrated from pull_request to gain write
+  access (e.g., to post PR comments or add labels) without understanding the
+  checkout difference.
+fix: |
+  If the goal is to build and test PR code, use on: pull_request instead of
+  pull_request_target. pull_request runs in the fork context with limited
+  permissions, which is the correct and safe choice for CI testing.
+
+  Reserve pull_request_target only for operations that specifically need write
+  permissions or secrets AND that do NOT execute untrusted PR code (e.g.,
+  adding labels based on event metadata, posting a comment using a stored
+  token). If pull_request_target must check out PR code, consult the GitHub
+  Security Lab advisory on pwn requests first — the attack surface is
+  significant.
+fix_code:
+  - language: yaml
+    label: 'Preferred: use pull_request for code testing workflows (runs against PR head safely)'
+    code: |
+      on:
+        pull_request:
+          branches: [main]
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          permissions:
+            contents: read
+          steps:
+            - uses: actions/checkout@v4
+              # No ref needed — pull_request automatically checks out the merge commit
+            - run: npm ci && npm test
+              shell: bash
+  - language: yaml
+    label: 'Safe pull_request_target: metadata-only operations — no checkout of PR code'
+    code: |
+      on:
+        pull_request_target:
+          types: [opened, synchronize, labeled]
+
+      jobs:
+        label:
+          runs-on: ubuntu-latest
+          permissions:
+            pull-requests: write
+          steps:
+            # Safe: uses only github.event data, does NOT check out PR code
+            - name: Add triage label
+              uses: actions/github-script@v7
+              with:
+                script: |
+                  await github.rest.issues.addLabels({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: context.payload.pull_request.number,
+                    labels: ['needs-review']
+                  });
+prevention:
+  - 'Default to on: pull_request for all CI testing workflows — it checks out PR code correctly and runs with limited permissions'
+  - 'Only use pull_request_target when write permissions or secrets are required AND untrusted PR code is never executed'
+  - 'If pull_request_target is in a workflow, verify there is NO actions/checkout step (or that it explicitly uses a trusted ref)'
+  - 'Review the GitHub Security Lab pwn requests advisory before combining pull_request_target with any form of code execution from the PR'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target'
+    label: 'GitHub Docs: pull_request_target event'
+  - url: 'https://securitylab.github.com/research/github-actions-preventing-pwn-requests/'
+    label: 'GitHub Security Lab: Preventing pwn requests in GitHub Actions'
+  - url: 'https://github.com/orgs/community/discussions/15669'
+    label: 'GitHub Community: pull_request_target and checkout behavior'

package/errors/yaml-syntax/composite-action-run-step-missing-shell.yml

@@ -0,0 +1,93 @@
+id: yaml-syntax-042
+title: 'Composite action run steps require explicit shell property — no default shell is applied'
+category: yaml-syntax
+severity: error
+tags:
+  - composite-action
+  - shell
+  - run-step
+  - action-yaml
+  - validation-error
+patterns:
+  - regex: 'Required property is missing: shell'
+    flags: 'i'
+  - regex: 'The `shell` property must be set'
+    flags: 'i'
+  - regex: 'shell is required for `run` step in composite action'
+    flags: 'i'
+error_messages:
+  - 'Required property is missing: shell'
+  - 'The `shell` property must be set for step `run` in composite actions'
+  - "Error: Unexpected value ''"
+root_cause: |
+  Regular workflow jobs default to bash on Linux and macOS, and pwsh on
+  Windows, when the shell property is omitted from a run step. Composite
+  actions (using: composite) do not inherit any default shell — every run
+  step must explicitly declare a shell value such as bash, pwsh, sh, or cmd.
+
+  This inconsistency frequently catches developers who copy run steps from a
+  workflow job into a composite action's action.yml without adding shell: bash.
+  The error surfaces immediately on the first run and is caught by the runner's
+  action schema validation, but the message can be confusing because shell is
+  a property developers rarely need to specify in regular workflows.
+
+  The GitHub Actions runner enforces this requirement because composite actions
+  must be portable across multiple callers (Linux, macOS, Windows) and the
+  runner has no basis to assume which shell is appropriate without the caller
+  specifying one.
+fix: |
+  Add shell: bash (or shell: pwsh on Windows-targeted steps, shell: sh for
+  minimal Alpine images) to every run step in the composite action's
+  action.yml. If the action must support multiple operating systems, use a
+  conditional expression to select the shell based on runner.os.
+fix_code:
+  - language: yaml
+    label: 'action.yml: add explicit shell to every run step in a composite action'
+    code: |
+      name: My Composite Action
+      description: 'Example composite action with correct shell declarations'
+      runs:
+        using: composite
+        steps:
+          - name: Install dependencies
+            run: npm ci
+            shell: bash
+
+          - name: Build
+            run: npm run build
+            shell: bash
+
+          - name: Run tests
+            run: npm test
+            shell: bash
+  - language: yaml
+    label: 'Cross-platform composite action: select shell via runner.os expression'
+    code: |
+      runs:
+        using: composite
+        steps:
+          - name: Platform-aware step
+            run: echo "Running on ${{ runner.os }}"
+            shell: ${{ runner.os == 'Windows' && 'pwsh' || 'bash' }}
+
+          - name: Windows-only step
+            if: runner.os == 'Windows'
+            run: Write-Host "Windows step"
+            shell: pwsh
+
+          - name: Unix step
+            if: runner.os != 'Windows'
+            run: echo "Unix step"
+            shell: bash
+prevention:
+  - 'Add shell: bash to every run step when authoring or editing a composite action — treat it as required boilerplate'
+  - 'Use actionlint or the VS Code GitHub Actions extension to surface missing shell properties before committing'
+  - 'Keep a composite action template or snippet that includes shell: bash by default in every run step'
+  - 'When converting a workflow job to a composite action, do a search for all run: blocks and add shell: to each'
+docs:
+  - url: 'https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#runsusing-for-composite-actions'
+    label: 'GitHub Docs: Metadata syntax for composite actions'
+  - url: 'https://github.com/actions/runner/issues/835'
+    label: 'actions/runner #835: Composite actions should have a default shell'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell'
+    label: 'GitHub Docs: Workflow syntax — steps.shell'

package/package.json

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