@htekdev/actions-debugger 1.0.58 → 1.0.59

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/package.json

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