@htekdev/actions-debugger 1.0.133 → 1.0.134

package/errors/known-unsolved/known-unsolved-078.yml

@@ -0,0 +1,91 @@
+id: known-unsolved-078
+title: 'Copilot agent branches not available in `workflow_dispatch` branch picker — cannot manually target Copilot branches'
+category: known-unsolved
+severity: limitation
+tags:
+  - workflow_dispatch
+  - copilot-agent
+  - branch-picker
+  - manual-trigger
+  - github-copilot
+  - ui-limitation
+patterns:
+  - regex: 'copilot.*branch.*not.*available|copilot.*branch.*missing.*dispatch'
+    flags: 'i'
+  - regex: 'workflow_dispatch.*copilot.*branch|copilot.*agent.*branch.*trigger'
+    flags: 'i'
+error_messages:
+  - "# No error message — Copilot agent branches simply do not appear in the branch selector"
+root_cause: |
+  When GitHub Copilot coding agent creates a branch to work on an assigned task,
+  the branch uses a namespaced prefix (`copilot/` by default, e.g.,
+  `copilot/fix-issue-123`). These branches are created and owned by the Copilot agent.
+
+  The GitHub Actions UI for `workflow_dispatch` presents a branch picker dropdown
+  that allows users to select which branch to run the workflow against. However,
+  Copilot agent branches are NOT included in this branch picker.
+
+  This is a UI-level platform limitation: GitHub filters the branch list shown in the
+  `workflow_dispatch` selector and excludes Copilot-owned branches from the list.
+  There is no documented API reason why this would be necessary — the branches exist
+  and are valid git refs — but the UI omits them.
+
+  As a workaround, the GitHub CLI or REST API CAN be used to trigger a
+  `workflow_dispatch` run targeting a Copilot branch by supplying the `ref` parameter
+  explicitly (bypassing the UI picker).
+
+  This issue was reported in runner#4246 (Feb 2026, 15 reactions) and remained open
+  as of June 2026. No ETA for a fix has been provided.
+
+  Note: This is a separate issue from Copilot agent PR workflows requiring approval
+  before running (triggers-027). That entry covers automatic workflows on Copilot PRs;
+  this entry covers the inability to manually dispatch TO a Copilot branch via the UI.
+fix: |
+  There is no UI fix — Copilot agent branches cannot be selected in the GitHub Actions
+  web interface workflow_dispatch branch picker.
+
+  **Workaround: use the GitHub CLI to trigger workflow_dispatch with an explicit ref:**
+  ```bash
+  gh workflow run <workflow-file.yml> --ref copilot/fix-issue-123
+  ```
+
+  **Workaround: use the GitHub REST API:**
+  ```bash
+  curl -X POST \
+    -H "Authorization: Bearer $GITHUB_TOKEN" \
+    -H "Accept: application/vnd.github+json" \
+    https://api.github.com/repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches \
+    -d '{"ref":"copilot/fix-issue-123","inputs":{}}'
+  ```
+
+  Both the CLI and API accept any valid branch ref, including Copilot branches,
+  even though the UI does not display them.
+fix_code:
+  - language: yaml
+    label: "Trigger workflow_dispatch on a Copilot branch via GitHub CLI (run from local terminal or another workflow)"
+    code: |
+      # Run locally or in a helper workflow step:
+      # gh workflow run deploy.yml --ref copilot/fix-issue-123
+
+      # Or call via the REST API in a workflow step:
+      - name: Dispatch workflow on Copilot branch
+        run: |
+          gh workflow run deploy.yml \
+            --ref "${{ github.head_ref }}" \
+            --repo ${{ github.repository }}
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+prevention:
+  - "Use the GitHub CLI (gh workflow run --ref <branch>) instead of the UI when targeting Copilot branches"
+  - "Use the REST API dispatches endpoint with an explicit ref to trigger workflows on any branch"
+  - "Follow runner#4246 for updates on when UI support for Copilot branches may be added"
+  - "Build automation that runs in workflow_run triggered by the Copilot branch's push event instead of requiring manual dispatch"
+docs:
+  - url: "https://github.com/actions/runner/issues/4246"
+    label: "runner#4246 — Cannot trigger workflows manually targeting a copilot agent branch (Feb 2026, 15 reactions)"
+  - url: "https://cli.github.com/manual/gh_workflow_run"
+    label: "GitHub CLI — gh workflow run (supports --ref for any branch)"
+  - url: "https://docs.github.com/en/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event"
+    label: "GitHub REST API — Create a workflow dispatch event (accepts any ref)"
+  - url: "https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent-in-github"
+    label: "GitHub Docs — Using Copilot coding agent"

package/errors/runner-environment/runner-environment-247.yml

@@ -0,0 +1,73 @@
+id: runner-environment-247
+title: '`apt-get install` stalls ~75 seconds on ubuntu-24.04 — "Processing triggers for man-db" post-install hook'
+category: runner-environment
+severity: warning
+tags:
+  - ubuntu-24.04
+  - apt-get
+  - man-db
+  - package-install
+  - performance
+  - slow
+patterns:
+  - regex: 'Processing triggers for man-db \('
+    flags: 'i'
+  - regex: 'man-db.*stall|stall.*man-db'
+    flags: 'i'
+error_messages:
+  - "Processing triggers for man-db (2.12.0-4build2) ..."
+  - "Processing triggers for man-db (2.12.0-4build2) ..."
+root_cause: |
+  On ubuntu-24.04 runners, installing any package that triggers the `man-db` post-install
+  hook causes a ~75-second stall during the `apt-get install` step.
+
+  The `man-db` daemon (which indexes manual pages for `man` lookups) has a post-install
+  trigger that runs `mandb` to rebuild the manual page database after packages are
+  installed. On ubuntu-24.04, this database rebuild operation runs synchronously and
+  takes approximately 60-90 seconds, blocking the apt post-install phase.
+
+  Any package that installs manual pages (cmake, make, build-essential, gcc, etc.)
+  triggers this slow hook. Workflows that install multiple packages in a single
+  `apt-get install` step will still only pay the cost once (one rebuild per transaction),
+  but even a single apt install with man pages will stall for over a minute.
+
+  The `man-db` package is installed by default on ubuntu-24.04 runner images. This
+  issue was reported in September 2025 and remains open as of June 2026 (runner#4030).
+fix: |
+  Option 1 — Remove man-db before running apt-get install commands:
+  ```yaml
+  - name: Remove man-db to prevent slow post-install trigger
+    run: sudo apt-get remove --purge -y man-db
+  ```
+  After removing man-db, all subsequent apt installs skip the man page indexing trigger.
+
+  Option 2 — Disable the man-db auto-update file (lighter weight):
+  ```yaml
+  - name: Disable man-db auto-update
+    run: sudo rm -f /var/lib/man-db/auto-update
+  ```
+  This deletes the sentinel file that triggers auto-update, preventing the stall without
+  uninstalling man-db.
+
+  Option 3 — Set DEBIAN_FRONTEND and skip recommended packages (partial mitigation):
+  Some packages still trigger man-db via direct page installation, but combining
+  `--no-install-recommends` reduces the set of affected packages.
+fix_code:
+  - language: yaml
+    label: "Remove man-db before apt-get installs to eliminate the stall"
+    code: |
+      - name: Remove man-db (prevents ~75s stall on ubuntu-24.04)
+        run: sudo apt-get remove --purge -y man-db
+
+      - name: Install dependencies
+        run: sudo apt-get install -y cmake make build-essential
+prevention:
+  - "Remove or disable man-db at the start of jobs that run apt-get install on ubuntu-24.04"
+  - "Use sudo rm -f /var/lib/man-db/auto-update as a lighter-weight alternative to removing the package"
+  - "Combine all apt-get installs into a single command to pay the man-db trigger cost only once"
+  - "Monitor job timing — if an apt step takes 75+ extra seconds on ubuntu-24.04, man-db is the cause"
+docs:
+  - url: "https://github.com/actions/runner/issues/4030"
+    label: "GitHub runner#4030 — man-db trigger severely stalls package installation on ubuntu-24.04"
+  - url: "https://manpages.ubuntu.com/manpages/noble/man8/mandb.8.html"
+    label: "Ubuntu mandb(8) manual — man page database indexer"

package/errors/runner-environment/runner-environment-248.yml

@@ -0,0 +1,106 @@
+id: runner-environment-248
+title: '`actions/checkout` causes "Duplicate header: Authorization" — git returns 400 on subsequent git operations'
+category: runner-environment
+severity: error
+tags:
+  - checkout
+  - git
+  - authorization
+  - http-extraheader
+  - credentials
+  - 400
+  - duplicate-header
+patterns:
+  - regex: 'Duplicate header.*Authorization|remote.*Duplicate header.*Authorization'
+    flags: 'i'
+  - regex: 'fatal.*unable to access.*The requested URL returned error: 400'
+    flags: 'i'
+  - regex: 'http\.extraheader.*AUTHORIZATION.*duplicate|duplicate.*AUTHORIZATION.*extraheader'
+    flags: 'i'
+error_messages:
+  - "remote: Duplicate header: \"Authorization\""
+  - "fatal: unable to access 'https://github.com/org/repo/': The requested URL returned error: 400"
+  - "Error: The process '/usr/bin/git' failed with exit code 128"
+root_cause: |
+  When `actions/checkout` runs, it configures git credentials by setting an
+  `http.extraheader` entry containing an `AUTHORIZATION: bearer <token>` header.
+  This header is added to git's global or repository-level config so that all
+  subsequent git operations over HTTPS are authenticated.
+
+  The "Duplicate header: Authorization" error occurs when a second Authorization
+  header is injected on top of the one already set by checkout. This can happen in
+  two scenarios:
+
+  1. **Pin to @main or an unstable tag**: Using `actions/checkout@main` (or any
+     edge/pre-release revision) picks up unreleased changes that may change the
+     credential injection mechanism. In some checkout versions, the http.extraheader
+     is written in a way that stacks with git's built-in credential manager, sending
+     two conflicting Authorization headers in the same HTTP request.
+
+  2. **Multiple checkout calls with persist-credentials: true** (the default):
+     The first checkout sets the global http.extraheader. A second checkout step
+     (e.g., checking out a second repository) may add a new header without first
+     removing the existing one, depending on the git version and checkout version.
+
+  GitHub's servers reject HTTP requests with two Authorization headers with HTTP 400,
+  returning "Duplicate header: Authorization" in the response. Git then reports
+  `fatal: unable to access ... The requested URL returned error: 400`.
+
+  The bug was reported in checkout#2299 (Nov 2025, 10 reactions) and checkout#2215
+  (Jul 2025, 8 reactions) and remained open as of June 2026.
+fix: |
+  Option 1 — Pin to a stable released version tag instead of @main:
+  Replace `actions/checkout@main` with a specific release tag (e.g.,
+  `actions/checkout@v4` or `actions/checkout@v4.2.2`). The stable release series
+  has known credential injection behaviour that does not produce duplicate headers.
+
+  Option 2 — Clear http.extraheader between checkout steps:
+  If you must run multiple checkout steps, add a step between them to clear the
+  credential header before the second checkout:
+  ```yaml
+  - name: Clear git credentials before second checkout
+    run: git config --global --unset-all http.extraheader || true
+  ```
+
+  Option 3 — Use token: input only on the checkout that needs it and set
+  persist-credentials: false on checkouts that do not need to push:
+  ```yaml
+  - uses: actions/checkout@v4
+    with:
+      persist-credentials: false
+  ```
+fix_code:
+  - language: yaml
+    label: "Pin to stable checkout version to avoid duplicate header bug"
+    code: |
+      - name: Checkout repository
+        uses: actions/checkout@v4   # Pin to stable tag, NOT @main
+        with:
+          fetch-depth: 0
+
+  - language: yaml
+    label: "Clear git extraheader between multiple checkout steps"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          repository: org/first-repo
+
+      - name: Clear git credentials
+        run: git config --global --unset-all http.extraheader || true
+
+      - uses: actions/checkout@v4
+        with:
+          repository: org/second-repo
+          path: second-repo
+prevention:
+  - "Never pin actions to @main or mutable tags — always use immutable version tags (e.g., @v4 or @v4.2.2)"
+  - "If using multiple checkout steps, set persist-credentials: false on steps that don't require pushing"
+  - "Check git config --global --list | grep extraheader if unexpected 400 errors occur on git operations"
+  - "Upgrade to the latest stable actions/checkout release when a new version is available"
+docs:
+  - url: "https://github.com/actions/checkout/issues/2299"
+    label: "checkout#2299 — Duplicate header: Authorization (Nov 2025, 10 reactions)"
+  - url: "https://github.com/actions/checkout/issues/2215"
+    label: "checkout#2215 — actions/checkout@v4 fails with Duplicate header: Authorization, 400 (Jul 2025, 8 reactions)"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable"
+    label: "GitHub Actions security hardening — credential best practices"

package/errors/silent-failures/silent-failures-122.yml

@@ -0,0 +1,102 @@
+id: silent-failures-122
+title: '`fetch-tags: false` is silently ignored when `fetch-depth: 0` — all tags are still fetched'
+category: silent-failures
+severity: silent-failure
+tags:
+  - checkout
+  - fetch-tags
+  - fetch-depth
+  - git
+  - tags
+  - shallow-clone
+  - option-conflict
+patterns:
+  - regex: 'fetch-tags.*false.*fetch-depth.*0|fetch-depth.*0.*fetch-tags.*false'
+    flags: 'i'
+  - regex: 'tags.*still.*fetched|fetching.*tags.*despite.*false'
+    flags: 'i'
+error_messages:
+  - "# No error message — tags are silently fetched despite fetch-tags: false"
+root_cause: |
+  `actions/checkout` provides two related but conflicting inputs:
+  - `fetch-depth: 0` — fetches ALL commits and branches (unshallow clone); this
+    implicitly fetches ALL tags as well because full history requires resolving all
+    tag references
+  - `fetch-tags: false` — instructs the action NOT to fetch tags
+
+  When BOTH options are used together (`fetch-depth: 0` and `fetch-tags: false`),
+  `fetch-tags: false` is silently ignored. The full-history fetch that `fetch-depth: 0`
+  triggers uses a git fetch command that includes tag references, and the action does
+  not apply a `--no-tags` flag in this code path.
+
+  As a result, all repository tags end up in the local clone even though the workflow
+  explicitly requested `fetch-tags: false`. There is no error, warning, or annotation
+  — the tags are simply present.
+
+  This is a code-path gap in actions/checkout rather than a documented design decision.
+  The issue was reported in checkout#2195 (Jun 2025, 10 reactions) and remained open
+  as of June 2026.
+
+  Common situations where this matters:
+  - Workflows that use `git describe` and want to avoid picking up pre-release or
+    unrelated tags from the full history
+  - Versioning scripts that filter by tag presence to determine release status
+  - Workflows that check `git tag -l` to decide whether to create a new tag
+fix: |
+  Since `fetch-tags: false` is not honoured with `fetch-depth: 0`, the workaround is
+  to explicitly delete the fetched tags in a step immediately after checkout:
+
+  ```yaml
+  - uses: actions/checkout@v4
+    with:
+      fetch-depth: 0
+      fetch-tags: false  # Has no effect — tags are fetched anyway
+
+  - name: Remove all fetched tags (workaround for fetch-depth:0 + fetch-tags:false bug)
+    run: git tag -d $(git tag -l) || true
+  ```
+
+  Alternatively, if the goal is to avoid tag resolution during git operations, use
+  `--no-tags` in subsequent git fetch calls:
+  ```yaml
+  - run: git fetch --no-tags origin
+  ```
+
+  If the full commit history is needed but not all tags, also consider filtering
+  the specific tags needed using `git fetch origin refs/tags/<specific-tag>:refs/tags/<specific-tag>`
+  after deleting the unwanted ones.
+fix_code:
+  - language: yaml
+    label: "Delete all fetched tags after checkout when fetch-tags: false is needed with full history"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          fetch-tags: false  # NOTE: currently ignored with fetch-depth: 0
+
+      - name: Delete all tags (workaround — fetch-tags:false ignored with fetch-depth:0)
+        run: |
+          TAGS=$(git tag -l)
+          if [ -n "$TAGS" ]; then
+            git tag -d $TAGS
+          fi
+
+  - language: yaml
+    label: "Fetch full history via explicit git command with --no-tags as an alternative"
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 1  # Shallow initial checkout
+
+      - name: Fetch full history without tags
+        run: git fetch --unshallow --no-tags
+prevention:
+  - "Do not rely on fetch-tags: false to suppress tag fetching when fetch-depth: 0 is also set — it has no effect"
+  - "If tag presence affects workflow logic, explicitly verify the tag state with git tag -l after checkout"
+  - "Track checkout#2195 for a fix in future actions/checkout releases"
+  - "As a workaround, delete all tags after checkout using: git tag -d $(git tag -l) || true"
+docs:
+  - url: "https://github.com/actions/checkout/issues/2195"
+    label: "checkout#2195 — fetch-tags: false still fetches tags if fetch-depth is 0 (Jun 2025, 10 reactions)"
+  - url: "https://github.com/actions/checkout#usage"
+    label: "actions/checkout Usage — fetch-depth and fetch-tags inputs"

package/package.json

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