@htekdev/actions-debugger 1.0.77 → 1.0.79

package/errors/caching-artifacts/merge-queue-branch-cache-isolation.yml

@@ -0,0 +1,80 @@
+id: caching-artifacts-045
+title: "Merge queue (merge_group) runs cannot restore cache saved by pull_request runs"
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - merge-queue
+  - merge_group
+  - cache-isolation
+  - branch-scoping
+  - cache-miss
+patterns:
+  - regex: 'Cache not found for input keys'
+    flags: i
+  - regex: 'gh-readonly-queue'
+    flags: i
+error_messages:
+  - "Cache not found for input keys:"
+  - "No cache found for key: Linux-node-"
+root_cause: |
+  GitHub Actions caches are branch-scoped. When the merge_group trigger fires,
+  GitHub creates a temporary branch named
+  gh-readonly-queue/main/pr-<number>-<sha> with a fresh merge commit. This
+  temporary branch has no prior cache entries, so every cache lookup is a cache
+  miss — even if the identical hashFiles() key was successfully saved during the
+  preceding pull_request run on the feature branch.
+
+  Branch-scoped cache fallback rules allow access to the base branch (e.g., main)
+  but NOT to arbitrary feature branches. The gh-readonly-queue/* branch is treated
+  as a new branch with no cache history and no access to feature-branch caches.
+  Only caches saved directly to main (or the configured merge target) are accessible
+  in merge queue runs.
+
+  The result: CI times effectively double. The pull_request run warms the cache
+  but the merge queue run cannot use it and must rebuild from scratch.
+fix: |
+  Seed caches on the base branch via push-triggered or scheduled workflows so
+  merge queue runs can restore from main's cache. Use restore-keys with a
+  branch-agnostic prefix to maximize fallback hit rate.
+fix_code:
+  - language: yaml
+    label: "Use restore-keys for base branch fallback"
+    code: |
+      - name: Cache dependencies
+        uses: actions/cache@v4
+        with:
+          path: ~/.npm
+          # Exact key includes lock file hash — works for push/PR
+          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+          # restore-keys fall back to base branch cache (accessible in merge_group)
+          restore-keys: |
+            ${{ runner.os }}-node-
+
+  - language: yaml
+    label: "Seed base branch cache via push workflow"
+    code: |
+      # Separate workflow to warm cache on main after every merge
+      on:
+        push:
+          branches: [main]
+
+      jobs:
+        warm-cache:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-node@v4
+              with:
+                node-version: '20'
+                cache: npm
+            - run: npm ci
+prevention:
+  - "Seed caches on your base branch (main) so merge queue runs can restore from it."
+  - "Use branch-agnostic restore-keys prefixes — they survive the gh-readonly-queue/* branch context."
+  - "Avoid cache keys that include branch name or github.head_ref — they will never match in merge queue."
+  - "setup-node/setup-python cache: integration automatically includes restore-keys and handles this gracefully."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#merge_group"
+    label: "GitHub Actions: merge_group trigger"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache"
+    label: "GitHub Actions: Cache branch access restrictions"

package/errors/concurrency-timing/rerun-cancel-original-missing-run-attempt.yml

@@ -0,0 +1,67 @@
+id: concurrency-timing-039
+title: "Manual re-run cancels original run when concurrency group omits github.run_attempt"
+category: concurrency-timing
+severity: error
+tags:
+  - concurrency
+  - re-run
+  - cancel-in-progress
+  - run-attempt
+  - manual-rerun
+patterns:
+  - regex: 'This run was cancelled'
+    flags: i
+  - regex: 'run_attempt'
+    flags: i
+error_messages:
+  - "This run was cancelled."
+  - "A run for this workflow is already in progress."
+root_cause: |
+  When cancel-in-progress: true is set and the concurrency group key does not
+  include github.run_attempt, every manual re-run of a workflow is treated as a
+  duplicate of the original run (since run_id and ref are the same). The re-run
+  immediately cancels the still-executing original attempt, or the concurrency
+  group queues the re-run and cancels any pending run — which may be the active
+  original.
+
+  The run_id is stable across re-runs but run_attempt increments (1, 2, 3...).
+  Without run_attempt in the concurrency group key, GitHub has no way to
+  distinguish re-run attempt 2 from the still-running attempt 1.
+
+  This produces confusing CI failures: a developer clicks "Re-run jobs" on a
+  failed workflow and immediately sees the original (or the re-run itself)
+  cancelled by the concurrency system.
+fix: |
+  Include github.run_attempt in the concurrency group key so each attempt is
+  treated as a distinct slot. This allows re-runs to coexist with or cleanly
+  supersede the original without unexpected cancellations.
+fix_code:
+  - language: yaml
+    label: "Include run_attempt in concurrency group key"
+    code: |
+      # WRONG: re-runs and originals share the same concurrency slot
+      # concurrency:
+      #   group: ${{ github.workflow }}-${{ github.ref }}
+      #   cancel-in-progress: true
+
+      # CORRECT: each attempt gets its own slot, preventing cross-attempt cancellation
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}-${{ github.run_attempt }}
+        cancel-in-progress: true
+
+  - language: yaml
+    label: "Alternative: cancel-in-progress only for push/PR, not re-runs"
+    code: |
+      concurrency:
+        group: ${{ github.workflow }}-${{ github.ref }}
+        # Only cancel-in-progress for first attempt; re-runs are never cancelled
+        cancel-in-progress: ${{ github.run_attempt == 1 }}
+prevention:
+  - "Always include github.run_attempt in concurrency group keys when cancel-in-progress: true is set."
+  - "Test re-run behavior explicitly — concurrency cancellation bugs only surface when you manually re-run."
+  - "Consider using cancel-in-progress: ${{ github.run_attempt == 1 }} to preserve re-run integrity."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#concurrency"
+    label: "GitHub Actions: Concurrency syntax"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#github-context"
+    label: "GitHub Actions: github.run_attempt context"

package/errors/runner-environment/macos-15-python-command-not-found.yml

@@ -0,0 +1,103 @@
+id: runner-environment-142
+title: "macOS-15 Sequoia Removes system python and python2 Stubs — Command Not Found in Workflows"
+category: runner-environment
+severity: error
+tags:
+  - macos
+  - macos-15
+  - macos-latest
+  - python2
+  - python
+  - sequoia
+  - setup-python
+patterns:
+  - regex: 'python[23]?: command not found'
+    flags: 'i'
+  - regex: '/usr/bin/python.*[Nn]o such file'
+    flags: ''
+  - regex: 'xcrun: error:.*python.*not a developer tool'
+    flags: 'i'
+  - regex: 'env: python: No such file or directory'
+    flags: ''
+error_messages:
+  - "python: command not found"
+  - "python2: command not found"
+  - "/usr/bin/python: No such file or directory"
+  - "env: python: No such file or directory"
+  - "xcrun: error: unable to find utility 'python', not a developer tool or in PATH"
+root_cause: |
+  Apple removed all Python stubs from macOS in macOS 15 (Sequoia). On macOS 12 through 14,
+  running `python` or `python2` would show a dialog prompting users to install Command Line
+  Tools, but the stub binary was present in /usr/bin/python so the command was technically
+  found (it just exited non-zero in CI where dialogs are suppressed). macOS 15 removed
+  these stubs entirely — /usr/bin/python and /usr/bin/python2 no longer exist.
+
+  GitHub Actions macos-15 runners and macos-latest (which resolves to macos-15 on 2025+
+  runners) have no `python` or `python2` in PATH unless explicitly installed via
+  actions/setup-python or Homebrew.
+
+  Affected workflow patterns:
+  - `run: python script.py` without a preceding setup-python step
+  - Build tools that internally call `python` (node-gyp, certain CMake scripts,
+    legacy Makefiles, scons, gyp-based builds)
+  - Shell scripts with `#!/usr/bin/env python` shebangs
+  - `pip` commands (also absent without setup-python)
+
+  Python 2 is also fully removed from Homebrew — `brew install python@2` is no longer
+  available. Any remaining Python 2 dependency must be ported to Python 3.
+fix: |
+  Use actions/setup-python to install Python explicitly on macOS runners.
+  Set the python-version to the version your workflow needs (3.12 or higher recommended).
+
+  For node-gyp or native module builds that internally call `python`, set the
+  npm_config_python environment variable to point to the Python 3 binary from
+  setup-python.
+
+  For shell scripts with `#!/usr/bin/env python` shebangs, update the shebang to
+  `#!/usr/bin/env python3` or call the script explicitly with `python3 script.py`.
+fix_code:
+  - language: yaml
+    label: "Add actions/setup-python before any step that needs python"
+    code: |
+      jobs:
+        build:
+          runs-on: macos-latest
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-python@v5
+              with:
+                python-version: '3.12'
+            - name: Run script
+              run: python script.py       # resolves to Python 3.12 from setup-python
+  - language: yaml
+    label: "Fix node-gyp calling python internally (native npm modules)"
+    code: |
+      steps:
+        - uses: actions/setup-python@v5
+          with:
+            python-version: '3.12'
+        - name: Install native modules
+          env:
+            npm_config_python: ${{ env.pythonLocation }}/bin/python3
+          run: npm ci
+  - language: yaml
+    label: "Cache Python between runs on macOS for faster CI"
+    code: |
+      steps:
+        - uses: actions/setup-python@v5
+          with:
+            python-version: '3.12'
+            cache: 'pip'           # caches pip downloads automatically
+        - run: pip install -r requirements.txt
+prevention:
+  - "Always use actions/setup-python on macOS jobs — never rely on system Python."
+  - "Search workflow files for bare `python` calls (without `3` suffix) and update to `python3` or add setup-python."
+  - "When migrating from macos-13 or macos-14 to macos-15, audit all steps invoking build tools (node-gyp, CMake, scons) that may call `python` internally."
+  - "Pin macos runner versions (e.g., macos-14) and plan an explicit upgrade window when testing macOS version bumps."
+docs:
+  - url: "https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md"
+    label: "macOS-15 runner image readme"
+  - url: "https://github.com/actions/setup-python"
+    label: "actions/setup-python"
+  - url: "https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes"
+    label: "Xcode 16 Release Notes (ships with macOS-15 runners)"

package/errors/runner-environment/ubuntu-24-mysql-84-native-password-removed.yml

@@ -0,0 +1,104 @@
+id: runner-environment-141
+title: "ubuntu-24.04 MySQL 8.4 Removes mysql_native_password Plugin — Client Authentication Fails"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu-24.04
+  - mysql
+  - mysql-8.4
+  - authentication
+  - service-container
+  - database
+patterns:
+  - regex: 'Plugin ''mysql_native_password'' is not loaded'
+    flags: 'i'
+  - regex: 'mysql_native_password.*cannot be loaded'
+    flags: 'i'
+  - regex: 'ER_NOT_SUPPORTED_AUTH_MODE'
+    flags: 'i'
+  - regex: 'Client does not support authentication protocol requested by server'
+    flags: 'i'
+error_messages:
+  - "ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded"
+  - "Authentication plugin 'mysql_native_password' cannot be loaded"
+  - "ER_NOT_SUPPORTED_AUTH_MODE: Client does not support authentication protocol requested by server; consider upgrading MySQL client"
+root_cause: |
+  Ubuntu 24.04 ships MySQL 8.4 LTS as its default MySQL version. MySQL 8.4 permanently
+  removed the `mysql_native_password` authentication plugin that was deprecated in
+  MySQL 8.0.4 and disabled by default in MySQL 8.0.34. In MySQL 8.4, the plugin
+  binary no longer exists — it cannot be re-enabled via server configuration.
+
+  The new default authentication plugin is `caching_sha2_password`, which requires
+  either a TLS/SSL connection or an RSA public key exchange during authentication.
+  Older MySQL client libraries that were compiled expecting mysql_native_password
+  behavior cannot authenticate against MySQL 8.4.
+
+  Commonly affected clients in GitHub Actions workflows:
+  - mysql2 Ruby gem versions < 0.5.6
+  - mysqljs/mysql npm package (use mysql2 npm package instead)
+  - mysql-connector-python < 8.0.28 without SSL configuration
+  - phpMyAdmin and other tools linking against older libmysqlclient
+
+  Workflows that use `image: mysql:latest` in service containers are at highest risk
+  as mysql:latest advanced to 8.4 and then 9.x after ubuntu-24.04 was released.
+fix: |
+  Option 1 — Pin MySQL service container to mysql:8.0:
+    Use `image: mysql:8.0` in your service container definition. MySQL 8.0 supports
+    mysql_native_password and is fully compatible with existing client libraries.
+    This is the fastest fix for affected workflows.
+
+  Option 2 — Update the MySQL client library:
+    - Ruby: upgrade mysql2 gem to >= 0.5.6 (caching_sha2_password support added)
+    - Node.js: replace `mysql` package with `mysql2` (>= 3.x)
+    - Python: upgrade mysql-connector-python to latest and configure ssl_disabled: false
+
+  Option 3 — Configure MySQL 8.4 to allow password auth with --default-auth:
+    MySQL 8.4 still supports caching_sha2_password for all connections. The issue is
+    the client, not the server. Update the client library — not the server auth policy.
+fix_code:
+  - language: yaml
+    label: "Pin MySQL service container to 8.0 to preserve native password support"
+    code: |
+      services:
+        mysql:
+          image: mysql:8.0          # Pin — mysql:latest is now 8.4+ (native_password removed)
+          env:
+            MYSQL_ROOT_PASSWORD: rootpassword
+            MYSQL_DATABASE: testdb
+          options: >-
+            --health-cmd="mysqladmin ping -h 127.0.0.1"
+            --health-interval=10s
+            --health-timeout=5s
+            --health-retries=5
+  - language: yaml
+    label: "Update mysql2 Ruby gem and use mysql:8.4 correctly"
+    code: |
+      # Gemfile — update to mysql2 >= 0.5.6 for caching_sha2_password support
+      # gem 'mysql2', '>= 0.5.6'
+
+      # Node.js — replace mysql (1.x) with mysql2 (3.x)
+      # npm install mysql2    # supports SHA2 auth; old mysql package does not
+
+      services:
+        mysql:
+          image: mysql:8.4
+          env:
+            MYSQL_ROOT_PASSWORD: rootpassword
+            MYSQL_DATABASE: testdb
+          options: >-
+            --health-cmd="mysqladmin ping -h 127.0.0.1"
+            --health-interval=10s
+            --health-timeout=5s
+            --health-retries=5
+prevention:
+  - "Always pin service container image versions (e.g., mysql:8.0) — mysql:latest advances silently and introduces breaking changes."
+  - "Test with the exact MySQL version your production environment uses, not mysql:latest."
+  - "When upgrading MySQL service container versions, update client gems/packages to versions that support caching_sha2_password."
+  - "Use the mysql health check option to fail fast when the container is misconfigured rather than timing out later."
+docs:
+  - url: "https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-0.html"
+    label: "MySQL 8.4.0 Release Notes — mysql_native_password removed"
+  - url: "https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/about-service-containers"
+    label: "GitHub Actions: about service containers"
+  - url: "https://github.com/brianmario/mysql2"
+    label: "mysql2 Ruby gem — caching_sha2_password support"

package/errors/runner-environment/ubuntu-24-pip-externally-managed-environment.yml

@@ -0,0 +1,90 @@
+id: runner-environment-140
+title: "ubuntu-24.04 pip install Fails With 'externally-managed-environment' — PEP 668 Blocks System Python"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu-24.04
+  - ubuntu-latest
+  - python
+  - pip
+  - pep-668
+  - venv
+patterns:
+  - regex: 'error: externally-managed-environment'
+    flags: 'i'
+  - regex: 'This environment is externally managed'
+    flags: 'i'
+  - regex: 'EXTERNALLY-MANAGED'
+    flags: ''
+error_messages:
+  - "error: externally-managed-environment"
+  - "× This environment is externally managed"
+  - "hint: See PEP 668 for the detailed specification."
+root_cause: |
+  Ubuntu 24.04 implements PEP 668, which marks the system Python environment as
+  "externally managed" — pip is not permitted to install or modify packages into
+  the system Python site-packages directory. The restriction is enforced by an
+  EXTERNALLY-MANAGED marker file placed at /usr/lib/python3.X/EXTERNALLY-MANAGED
+  by the Ubuntu package maintainers.
+
+  On GitHub Actions ubuntu-24.04 runners (and ubuntu-latest, which resolved to
+  ubuntu-24.04 in mid-2025), the default system Python 3 (3.12) ships this marker.
+  Any workflow step that calls `pip install` or `pip3 install` without a virtual
+  environment or the setup-python action will hit this error immediately.
+
+  Workflows migrated from ubuntu-22.04 — which did not enforce PEP 668 — will fail
+  on first run without any other changes. The error is clear in the output but
+  unexpected for workflows that previously relied on system-wide pip installs.
+fix: |
+  Option 1 — Use actions/setup-python (recommended):
+    Replace the bare system Python with a setup-python step. actions/setup-python
+    creates its own isolated Python installation outside the system path, making
+    pip install work without virtual environments or bypass flags.
+
+  Option 2 — Create a virtual environment:
+    Run `python3 -m venv .venv && source .venv/bin/activate` before pip install.
+    This is the correct long-term fix for any environment.
+
+  Option 3 — Pass --break-system-packages:
+    Append `--break-system-packages` to the pip install command. This bypasses
+    PEP 668 enforcement. Acceptable in ephemeral CI environments but not
+    recommended for production systems.
+fix_code:
+  - language: yaml
+    label: "Use actions/setup-python — recommended approach"
+    code: |
+      steps:
+        - uses: actions/checkout@v4
+        - uses: actions/setup-python@v5
+          with:
+            python-version: '3.12'
+        - name: Install dependencies
+          run: pip install -r requirements.txt   # works: isolated Python, not system
+  - language: yaml
+    label: "Create a virtual environment before pip install"
+    code: |
+      steps:
+        - uses: actions/checkout@v4
+        - name: Install in venv
+          run: |
+            python3 -m venv .venv
+            source .venv/bin/activate
+            pip install -r requirements.txt
+  - language: yaml
+    label: "Quick fix: --break-system-packages flag (CI-only workaround)"
+    code: |
+      steps:
+        - name: Install dependencies
+          run: pip install --break-system-packages -r requirements.txt
+prevention:
+  - "Use actions/setup-python on ubuntu-24.04 runners — do not rely on system Python for pip installs."
+  - "Audit all `pip install` steps when migrating from ubuntu-22.04 to ubuntu-24.04 or ubuntu-latest."
+  - "Pin your Python version in actions/setup-python to prevent unexpected changes when the runner default Python changes."
+  - "Cache the virtual environment with actions/cache using a hash of requirements.txt as the key to speed up runs."
+docs:
+  - url: "https://peps.python.org/pep-0668/"
+    label: "PEP 668 — Marking Python base environments as externally managed"
+  - url: "https://github.com/actions/setup-python"
+    label: "actions/setup-python"
+  - url: "https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes"
+    label: "Ubuntu 24.04 (Noble Numbat) Release Notes"

package/errors/runner-environment/ubuntu-snap-not-available-no-systemd.yml

@@ -0,0 +1,92 @@
+id: runner-environment-143
+title: "snap install Fails on All GitHub-Hosted Runners — snapd Requires systemd Which Is Absent in CI"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu
+  - snap
+  - snapd
+  - systemd
+  - package-management
+  - runner-limitation
+patterns:
+  - regex: 'cannot communicate with server.*snapd'
+    flags: 'i'
+  - regex: 'snap: command not found'
+    flags: 'i'
+  - regex: 'snapd\.socket.*connect.*no such file'
+    flags: 'i'
+  - regex: 'error: cannot list snaps: cannot communicate with server'
+    flags: 'i'
+error_messages:
+  - "error: cannot communicate with server: Post \"http+unix://%2Frun%2Fsnapd.socket/v2/snaps\": dial unix /run/snapd.socket: connect: no such file or directory"
+  - "snapd is not running"
+  - "snap: command not found"
+  - "cannot communicate with server: Post http+unix:///run/snapd.socket/v2/snaps: dial unix /run/snapd.socket: connect: no such file or directory"
+root_cause: |
+  GitHub-hosted Ubuntu runners do not run systemd as PID 1. They use a custom
+  initialization environment where systemd is not the init system. The snap package
+  manager (snapd) requires systemd for:
+  - Daemon lifecycle management (snapd.service unit)
+  - D-Bus socket activation (/run/snapd.socket)
+  - AppArmor profile enforcement for snap confinement
+  - Mount namespace management for snap application isolation
+
+  Without systemd, the snapd daemon never starts, and /run/snapd.socket does not
+  exist. Any `snap install` command immediately fails because the snap client
+  cannot reach the daemon socket to submit the install request.
+
+  This is a structural limitation of GitHub-hosted runners across ALL Ubuntu versions
+  (ubuntu-20.04, ubuntu-22.04, ubuntu-24.04, ubuntu-latest) and has not changed
+  since Actions was launched. Attempting to start snapd manually with `systemctl start snapd`
+  also fails because systemctl is non-functional without systemd.
+
+  While `snap` binary may be present in PATH on some runner images, it is non-functional
+  and the underlying daemon cannot be started in the current runner architecture.
+fix: |
+  Replace snap install with an alternative package source:
+
+  - Use apt/apt-get: Most snap packages have apt equivalents or PPA repositories
+  - Use dedicated GitHub Actions: Many popular tools have official or maintained Actions
+    (e.g., azure/setup-kubectl, helm/kind-action, hashicorp/setup-terraform)
+  - Download official binary releases: curl the release binary from GitHub Releases
+    or the tool's official download page, then move to /usr/local/bin
+  - Use Homebrew (macOS) or the tool's official install script
+fix_code:
+  - language: yaml
+    label: "Replace snap install kubectl with the official setup-kubectl action"
+    code: |
+      steps:
+        # Instead of: run: sudo snap install kubectl --classic
+        - uses: azure/setup-kubectl@v4
+          with:
+            version: 'v1.30.0'
+  - language: yaml
+    label: "Replace snap install helm with the official Helm install script"
+    code: |
+      steps:
+        # Instead of: run: sudo snap install helm --classic
+        - name: Install Helm
+          run: |
+            curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
+  - language: yaml
+    label: "Generic: replace snap install with direct binary download"
+    code: |
+      steps:
+        - name: Install tool via binary release (snap alternative)
+          run: |
+            VERSION="1.2.3"
+            curl -fsSL "https://example.com/releases/${VERSION}/tool-linux-amd64.tar.gz" \
+              | tar -xz -C /usr/local/bin tool
+prevention:
+  - "Never use `snap install` in GitHub Actions — snapd does not work on any GitHub-hosted runner."
+  - "Search all workflow files for `snap install` and replace with apt, binary downloads, or official GitHub Actions."
+  - "When evaluating new tools for CI, prefer those distributed via apt, Homebrew, or binary releases over snap-only distributions."
+  - "Check the tool's GitHub repository for an official GitHub Action before writing a custom install step."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/3206"
+    label: "runner-images #3206: snap install fails on GitHub Actions (long-running issue)"
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners"
+    label: "GitHub-hosted runners overview"
+  - url: "https://snapcraft.io/docs/installing-snapd"
+    label: "Snapcraft: installing snapd (requires systemd)"

package/errors/silent-failures/fromjson-object-stored-in-env-stringifies.yml

@@ -0,0 +1,77 @@
+id: silent-failures-074
+title: "fromJSON() object or array stored in env: block silently becomes '[object Object]'"
+category: silent-failures
+severity: silent-failure
+tags:
+  - fromjson
+  - env-context
+  - type-coercion
+  - json-parsing
+  - stringification
+patterns:
+  - regex: 'env\s*:.*\$\{\{\s*fromJSON\('
+    flags: ims
+error_messages:
+  - "[object Object]"
+  - "Unexpected token 'o', \"[object O\"... is not valid JSON"
+root_cause: |
+  The fromJSON() function in GitHub Actions expressions parses a JSON string
+  into a typed value — object, array, boolean, or number. However, when the
+  result is assigned to an env: variable, the Actions runner coerces the value
+  to a string using JavaScript's default toString(). For objects this produces
+  the literal string [object Object]; for arrays it produces a comma-joined
+  string (e.g., a,b,c).
+
+  The step exits with code 0 and the env variable appears set, but its value is
+  the stringified form rather than the JSON structure the developer expected.
+  Subsequent steps that reference ${{ env.CONFIG }} or echo the variable and
+  pipe it through jq will receive [object Object] and fail to parse — or silently
+  produce wrong results.
+
+  Booleans and numbers survive correctly: fromJSON('true') in env: produces the
+  string 'true', and fromJSON('42') produces '42' — these are the only safe uses.
+fix: |
+  Pass structured JSON data between steps via GITHUB_OUTPUT (as a raw JSON
+  string), then consume the stored string with fromJSON() in downstream
+  expression contexts. Never store objects or arrays via fromJSON() in env: blocks.
+fix_code:
+  - language: yaml
+    label: "Store JSON in GITHUB_OUTPUT, consume via fromJSON in expressions"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            # WRONG: fromJSON object in env: becomes '[object Object]'
+            # - name: Bad config
+            #   env:
+            #     CONFIG: ${{ fromJSON(inputs.config_json) }}
+            #   run: echo "$CONFIG" | jq .host  # fails: '[object Object]' is not JSON
+
+            # CORRECT: store raw JSON string in GITHUB_OUTPUT
+            - name: Store config
+              id: cfg
+              run: echo 'config=${{ inputs.config_json }}' >> $GITHUB_OUTPUT
+
+            # Access fields with fromJSON() directly in expression context
+            - name: Use config
+              run: |
+                echo "Host: ${{ fromJSON(steps.cfg.outputs.config).host }}"
+                echo "Port: ${{ fromJSON(steps.cfg.outputs.config).port }}"
+
+            # Scalar fromJSON values are safe in env: (boolean, number)
+            - name: Scalar fromJSON is fine
+              env:
+                IS_PROD: ${{ fromJSON(inputs.is_prod) }}
+                TIMEOUT: ${{ fromJSON(inputs.timeout) }}
+              run: echo "prod=$IS_PROD timeout=$TIMEOUT"
+prevention:
+  - "Never assign fromJSON() results that produce objects or arrays to env: variables."
+  - "Use fromJSON() inline in expression contexts (${{ fromJSON(x).field }}) rather than materializing into env vars."
+  - "Store JSON blobs as raw strings in GITHUB_OUTPUT and parse with jq in shell or fromJSON() in expressions."
+  - "For object env vars, keep the value as a raw JSON string and parse in shell with jq or python -c."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#fromjson"
+    label: "GitHub Actions: fromJSON expression function"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs"
+    label: "GitHub Actions: Passing information between jobs"

package/errors/triggers/event-types-unknown-value-silently-ignored.yml

@@ -0,0 +1,89 @@
+id: triggers-053
+title: "Unknown or misspelled values in on.<event>.types[] are silently ignored — workflow never triggers"
+category: triggers
+severity: silent-failure
+tags:
+  - types-filter
+  - trigger
+  - typo
+  - pull-request
+  - silent-failure
+patterns:
+  - regex: 'types\s*:\s*\[.*(?:syncronize|synchronised|synchronize d|re-opened|labeld|assign)\]'
+    flags: i
+  - regex: 'types\s*:\s*\n(?:\s+-\s+\w+\n)*\s+-\s+(?!opened|closed|reopened|synchronize|labeled|unlabeled|assigned|unassigned|review_requested|ready_for_review|converted_to_draft|locked|unlocked|milestoned|demilestoned|edited)\w'
+    flags: im
+error_messages:
+  - "Workflow is not triggered"
+  - "No runs found"
+root_cause: |
+  GitHub Actions silently discards unrecognized values in the types: filter
+  array for pull_request, pull_request_target, and other typed events. There is
+  no validation error, no schema warning, and no run log entry — the workflow
+  simply never fires for the intended activity type.
+
+  The most common cause is a typo in a well-known type name:
+    - syncronize  (correct: synchronize)
+    - re-opened   (correct: reopened)
+    - labeld      (correct: labeled)
+    - closed      (correct: closed — note: not 'merged')
+
+  A second common cause is listing only the new type while forgetting that the
+  default types are no longer active. For example, types: [synchronize] drops
+  the implicit opened and reopened behaviors, so a newly opened PR will not
+  trigger CI at all.
+
+  actionlint >=0.7.0 can detect unknown type values but is not always used in
+  local development workflows.
+fix: |
+  Verify all type values against the official list for each event. Include all
+  intended types explicitly — once types: is specified, the defaults no longer
+  apply.
+fix_code:
+  - language: yaml
+    label: "Correct types for pull_request CI — always include all intended types"
+    code: |
+      on:
+        pull_request:
+          # WRONG examples (silently never trigger):
+          # types: [opened, syncronize, re-opened]   # typos
+          # types: [synchronize]                     # drops opened/reopened
+
+          # CORRECT: include all intended activity types
+          types:
+            - opened
+            - synchronize
+            - reopened
+
+  - language: yaml
+    label: "All valid pull_request types for reference"
+    code: |
+      on:
+        pull_request:
+          types:
+            # Commonly needed for CI:
+            - opened          # new PR created
+            - synchronize     # new commit pushed to PR branch
+            - reopened        # closed PR re-opened
+            # Useful for label-gated workflows:
+            - labeled
+            - unlabeled
+            # Draft/review flow:
+            - ready_for_review
+            - converted_to_draft
+            # Assignment:
+            - assigned
+            - unassigned
+            - review_requested
+prevention:
+  - "Run actionlint (>=0.7.0) in CI to detect unknown type values — it reports them as errors."
+  - "When adding types:, explicitly list ALL types you need — defaults no longer apply once types: is present."
+  - "After changing types:, trigger one manual test run per type to confirm the filter is working."
+  - "Use the GitHub Actions VS Code extension — it underlines unknown type values as warnings."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request"
+    label: "GitHub Actions: pull_request event types"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target"
+    label: "GitHub Actions: pull_request_target event types"
+  - url: "https://rhysd.github.io/actionlint/"
+    label: "actionlint: GitHub Actions linter"

package/package.json

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