@htekdev/actions-debugger 1.0.117 → 1.0.119

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

@@ -0,0 +1,107 @@
+id: runner-environment-214
+title: 'setup-java Fails with "Invalid Version" for JetBrains Runtime 4-Part Semver (e.g. 17.0.8.1+1080.1)'
+category: runner-environment
+severity: error
+tags:
+  - setup-java
+  - jbr
+  - jetbrains-runtime
+  - java
+  - semver
+  - version-parsing
+  - windows
+  - ubuntu
+patterns:
+  - regex: 'Java setup process failed due to:\s*Invalid Version:\s*\d+\.\d+\.\d+\.\d+\+'
+    flags: 'i'
+  - regex: 'Invalid Version:\s*\d+\.\d+\.\d+\.\d+'
+    flags: 'i'
+  - regex: 'java setup.*failed.*Invalid Version'
+    flags: 'i'
+error_messages:
+  - 'Error: Java setup process failed due to: Invalid Version: 17.0.8.1+1080.1'
+  - 'Error: Java setup process failed due to: Invalid Version: 25.0.3+480.61'
+  - 'Error: Java setup process failed due to: Invalid Version: 21.0.5.1+1100.2'
+root_cause: |
+  JetBrains Runtime (JBR) version strings use a 4-part numeric format:
+  `major.minor.patch.update+build.sub-build` (e.g. `17.0.8.1+1080.1`).
+  This does NOT conform to standard semantic versioning (3-part numeric).
+
+  The `actions/setup-java` version resolver uses a semver parser internally.
+  When the user passes a full pinned JBR version string containing a 4-part
+  numeric prefix (the `.1` after the patch component), the parser throws:
+
+    "Invalid Version: 17.0.8.1+1080.1"
+
+  Affected distributions: `jetbrains` (JBR) distribution only.
+  Affected platforms: Ubuntu and Windows (both throw the same error).
+  Unaffected: Oracle, Temurin, Adopt, Corretto and other distributions whose
+  version strings use standard 3-part semver (e.g. `21.0.3+9`).
+
+  The root cause is that JBR independently versions patch updates
+  (the `.1` suffix), meaning a JBR patch release version is 4 integers deep,
+  which the bundled semver parser does not accept.
+
+  Tracked upstream: https://github.com/actions/setup-java/issues/1008 (open May 2026)
+  Fix PR: https://github.com/actions/setup-java/pull/1009 (isVersionSatisfies patch — pending merge)
+fix: |
+  Until https://github.com/actions/setup-java/pull/1009 is merged and released,
+  do NOT pin the full 4-part JBR version string. Use either:
+
+  1. The 3-part version prefix (major.minor.patch) — setup-java will resolve the
+     latest available JBR sub-build for that patch:
+
+       - uses: actions/setup-java@v5
+         with:
+           distribution: 'jetbrains'
+           java-version: '17.0.8'   # omit the .1 suffix
+
+  2. Just the major version for the latest JBR:
+
+       - uses: actions/setup-java@v5
+         with:
+           distribution: 'jetbrains'
+           java-version: '17'
+
+  3. The pre-release format accepted by the current parser (major.minor.patch
+     with the build metadata only, omitting the update digit):
+
+       - uses: actions/setup-java@v5
+         with:
+           distribution: 'jetbrains'
+           java-version: '17.0.8+1080.1'   # skip the 4th integer; use build metadata
+fix_code:
+  - language: yaml
+    label: 'Use 3-part version prefix to avoid "Invalid Version" on JBR'
+    code: |
+      - name: Set up JBR 17 (JetBrains Runtime)
+        uses: actions/setup-java@v5
+        with:
+          distribution: 'jetbrains'
+          java-version: '17.0.8'   # NOT '17.0.8.1+1080.1' — 4-part fails the parser
+  - language: yaml
+    label: 'Major-version pin (simplest, always resolves latest JBR for that major)'
+    code: |
+      - name: Set up JBR 25
+        uses: actions/setup-java@v5
+        with:
+          distribution: 'jetbrains'
+          java-version: '25'
+prevention:
+  - 'Check the JBR releases page to understand the version format before pinning.
+    JBR versions are `major.minor.patch.update+build.sub-build`; only use the
+    3-part prefix (major.minor.patch) or major-version-only with setup-java.'
+  - 'Watch https://github.com/actions/setup-java/pull/1009 for when the fix merges
+    so full 4-part JBR version strings become accepted.'
+  - 'For reproducibility without pinning the exact JBR sub-build, consider
+    using a `.java-version` file with a 3-part version string and referencing it
+    via `java-version-file:` in setup-java.'
+docs:
+  - url: 'https://github.com/actions/setup-java/issues/1008'
+    label: 'setup-java #1008 — Error parsing JBR version 17.0.8.1+1080.1 (open, May 2026)'
+  - url: 'https://github.com/actions/setup-java/pull/1009'
+    label: 'setup-java PR #1009 — fix: reject non-semver candidate versions in isVersionSatisfies (pending)'
+  - url: 'https://github.com/actions/setup-java?tab=readme-ov-file#supported-distributions'
+    label: 'setup-java README — Supported distributions (JetBrains / JBR)'
+  - url: 'https://github.com/JetBrains/JetBrainsRuntime/releases'
+    label: 'JetBrains Runtime releases — version format reference'

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

@@ -0,0 +1,93 @@
+id: runner-environment-215
+title: 'setup-node fails with EBADDEVENGINES when devEngines.packageManager.version does not match initial npm'
+category: runner-environment
+severity: error
+tags:
+  - setup-node
+  - npm
+  - devEngines
+  - EBADDEVENGINES
+  - package-manager
+  - npm-version
+patterns:
+  - regex: 'npm error code EBADDEVENGINES'
+    flags: 'i'
+  - regex: 'npm error EBADDEVENGINES.*Invalid devEngines\.packageManager'
+    flags: 'i'
+  - regex: 'npm error EBADDEVENGINES.*Invalid semver version.*does not match.*for "packageManager"'
+    flags: 'i'
+  - regex: '/npm config get cache\s*npm error code EBADDEVENGINES'
+    flags: 'is'
+error_messages:
+  - 'npm error code EBADDEVENGINES'
+  - 'npm error EBADDEVENGINES The developer of this package has specified the following through devEngines'
+  - 'npm error EBADDEVENGINES Invalid devEngines.packageManager'
+  - 'npm error EBADDEVENGINES Invalid semver version "^11.10.0" does not match "10.9.7" for "packageManager"'
+root_cause: |
+  actions/setup-node@v6 runs `npm config get cache` immediately after installing Node.js to
+  determine the npm cache path before activating the package-manager-cache feature. If
+  package.json declares a `devEngines.packageManager.version` constraint (Node.js 22.6+
+  feature) that the bundled npm does NOT satisfy, npm exits with EBADDEVENGINES before
+  returning the cache path.
+
+  The failure happens before setup-node has a chance to upgrade npm to the required version,
+  creating a catch-22: the action needs the cache path to set up, but npm won't answer
+  because the version constraint is not yet met.
+
+  Common scenario: project requires `npm@^11.10.0` (for `min-release-age` or other features
+  added in npm 11.x), but Node 22 ships with npm 10.x. The first `npm` invocation fails
+  immediately when devEngines enforcement is active.
+fix: |
+  Option 1 (recommended) — add `"onFail": "warn"` to the devEngines.packageManager block.
+  This downgrades version mismatches to warnings so npm commands still complete, letting
+  setup-node finish. Install the required npm version in a subsequent step.
+
+  Option 2 — pin Node.js to a version whose bundled npm satisfies devEngines (often
+  impractical).
+
+  Option 3 — set `package-manager-cache: false` in setup-node to skip the cache-path probe
+  entirely and manage npm caching separately.
+fix_code:
+  - language: yaml
+    label: 'Option 1 — add onFail: warn to package.json (fix the root cause)'
+    code: |
+      # In package.json:
+      # {
+      #   "devEngines": {
+      #     "packageManager": {
+      #       "name": "npm",
+      #       "version": "^11.10.0",
+      #       "onFail": "warn"        <-- add this
+      #     }
+      #   }
+      # }
+
+      # In workflow — install the required npm version after setup-node succeeds:
+      - uses: actions/setup-node@v6
+        with:
+          node-version-file: package.json
+      - run: npm install -g npm@^11.10.0
+  - language: yaml
+    label: 'Option 3 — disable package-manager-cache in setup-node'
+    code: |
+      - uses: actions/setup-node@v6
+        with:
+          node-version: '22'
+          package-manager-cache: false   # skip npm config get cache probe
+      - run: npm install -g npm@^11.10.0
+      - uses: actions/cache@v4
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+prevention:
+  - 'Always pair devEngines.packageManager.version with "onFail": "warn" unless the project must hard-fail on CI for version mismatches.'
+  - 'Use package-manager-cache: false in setup-node and handle npm caching manually when devEngines constraints are strict.'
+  - 'Track the Node.js release schedule to choose a version that ships with an npm satisfying devEngines requirements from day one.'
+  - 'Pin action version in workflow (e.g., actions/setup-node@v6.4.0) and test upgrades in a branch before rolling out.'
+docs:
+  - url: 'https://github.com/actions/setup-node/issues/1553'
+    label: 'setup-node#1553 — EBADDEVENGINES blocks cache-path probe (May 2026)'
+  - url: 'https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines'
+    label: 'npm docs — devEngines field and onFail option'
+  - url: 'https://github.com/nodejs/node/issues/62425'
+    label: 'Node.js#62425 — npm installation behavior on Node v22.22.2 with devEngines'

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

@@ -0,0 +1,82 @@
+id: runner-environment-216
+title: 'ubuntu-26.04 ships Helm 4 — `helm repo add --no-update` removed, causes unknown flag error'
+category: runner-environment
+severity: error
+tags:
+  - helm
+  - helm-4
+  - ubuntu-26
+  - tool-upgrade
+  - flag-removed
+patterns:
+  - regex: 'Error: unknown flag: --no-update'
+    flags: 'i'
+  - regex: 'unknown flag.*--no-update'
+    flags: 'i'
+error_messages:
+  - 'Error: unknown flag: --no-update'
+  - 'Error: flag provided but not defined: --no-update'
+root_cause: |
+  ubuntu-26.04 runner images install Helm 4 (via the `get-helm-4` installer script)
+  instead of Helm 3 used on ubuntu-22.04 and ubuntu-24.04. In Helm 4, the
+  `--no-update` flag was permanently removed from `helm repo add`
+  (breaking change: helm/helm#13614, released in Helm v4.0.0, November 2025).
+
+  In Helm 3, `helm repo add <name> <url> --no-update` was used to add a repo
+  without triggering a refresh of all configured repos. This was common in CI
+  pipelines to speed up `helm repo add` when many repos are configured. The
+  flag was first deprecated in Helm 3.7 and has been removed entirely in Helm 4
+  with no deprecated alias retained.
+
+  The runner-images commit 9e3319d (May 2026) introduced Helm 4 for ubuntu-26.04.
+  Any workflow using `runs-on: ubuntu-26.04` (or eventually `ubuntu-latest` when
+  it migrates to 26.04) that calls `helm repo add --no-update` will fail
+  immediately with `Error: unknown flag: --no-update`.
+fix: |
+  Remove the `--no-update` flag entirely. In Helm 4, `helm repo add` does not
+  update existing repos by default — the behavior the flag used to enforce is
+  now the default behavior.
+
+  If you need to force-update all repos after adding, use `helm repo update`.
+
+  To avoid Helm version surprises on ubuntu-26.04, pin a specific Helm version
+  using `azure/setup-helm` and pass the version explicitly.
+fix_code:
+  - language: yaml
+    label: 'Remove --no-update flag (Helm 4 default behavior)'
+    code: |
+      - name: Add Helm repo
+        run: |
+          # Helm 4 on ubuntu-26.04: --no-update flag has been removed.
+          # Helm 4 does not update existing repos by default (old --no-update behavior).
+          # Simply omit the flag:
+          helm repo add bitnami https://charts.bitnami.com/bitnami
+          # If you still need to update all repos afterwards:
+          # helm repo update
+
+  - language: yaml
+    label: 'Pin Helm version with azure/setup-helm to avoid version surprises'
+    code: |
+      - name: Set up Helm
+        uses: azure/setup-helm@v5
+        with:
+          version: '3.17.x'   # Pin to Helm 3 if your workflow isn't Helm 4 ready
+          # Or pin to a specific Helm 4 version:
+          # version: '4.2.x'
+
+      - name: Add Helm repo
+        run: helm repo add bitnami https://charts.bitnami.com/bitnami
+prevention:
+  - "Pin your Helm version with `azure/setup-helm` rather than relying on the pre-installed Helm on the runner."
+  - "When migrating to ubuntu-26.04, audit all `helm repo add` calls and remove any `--no-update` flags."
+  - "Check the Helm 4 migration guide at https://helm.sh/docs/topics/v4_migration/ before adopting ubuntu-26.04."
+  - "Add a CI step that prints `helm version` so version surprises are immediately visible in logs."
+docs:
+  - url: 'https://github.com/helm/helm/blob/main/CHANGELOG.md'
+    label: 'Helm 4 Changelog — breaking changes'
+  - url: 'https://helm.sh/docs/topics/v4_migration/'
+    label: 'Helm v4 Migration Guide'
+  - url: 'https://github.com/actions/runner-images/commit/9e3319d6b4acc306925295853d0ff41ddd5c40f0'
+    label: 'runner-images commit: ubuntu-26 ships Helm 4 (get-helm-4)'
+  - url: 'https://github.com/Azure/setup-helm'
+    label: 'azure/setup-helm action — pin Helm version'

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

@@ -0,0 +1,99 @@
+id: runner-environment-217
+title: 'ubuntu-26.04 Helm 4 — `helm install --atomic` fails with unknown flag error on Helm 4.0.x–4.1.0'
+category: runner-environment
+severity: error
+tags:
+  - helm
+  - helm-4
+  - ubuntu-26
+  - tool-upgrade
+  - flag-renamed
+  - atomic
+patterns:
+  - regex: 'Error: unknown flag: --atomic'
+    flags: 'i'
+  - regex: 'helm install.*Error.*unknown flag.*atomic'
+    flags: 'i'
+error_messages:
+  - 'Error: unknown flag: --atomic'
+  - 'Error: flag provided but not defined: --atomic'
+root_cause: |
+  ubuntu-26.04 runner images install Helm 4. In Helm 4, the `--atomic` flag was
+  renamed to `--rollback-on-failure`. On `helm upgrade`, the old `--atomic` flag
+  was retained as a deprecated alias that emits a warning. However, on
+  `helm install`, the `--atomic` binding was accidentally omitted in Helm 4.0.0,
+  so `helm install --atomic` fails with `Error: unknown flag: --atomic` on Helm
+  versions 4.0.0 through 4.1.0.
+
+  This was reported in helm/helm#31900 and fixed in Helm 4.1.1 via PR #31901
+  (March 4, 2026), which restored `--atomic` as a deprecated alias on
+  `helm install`. However, workflows that pin specific Helm 4 versions via
+  `azure/setup-helm` at versions 4.0.0–4.1.0, or any ubuntu-26.04 image built
+  before the Helm 4.1.1+ update, will still hit this error.
+
+  `--atomic` is extremely common in Kubernetes deployment workflows because it
+  auto-rolls back failed installs and waits for all pods to be Ready.
+fix: |
+  Replace `--atomic` with `--rollback-on-failure` in your `helm install`
+  command. The semantics are identical: on failure, Helm rolls back (uninstalls)
+  the release and returns a non-zero exit code.
+
+  Note: `--wait` is implicitly enabled when `--rollback-on-failure` is set.
+
+  If you must use `--atomic` (e.g., shared scripts that support both Helm 3 and 4),
+  pin Helm 3 with `azure/setup-helm` or ensure Helm 4.1.1+ is installed.
+fix_code:
+  - language: yaml
+    label: 'Replace --atomic with --rollback-on-failure (Helm 4 syntax)'
+    code: |
+      - name: Deploy chart
+        run: |
+          # Helm 4 on ubuntu-26.04: --atomic is removed from helm install (4.0.x-4.1.0).
+          # Use --rollback-on-failure instead (semantically identical):
+          helm install my-release ./chart \
+            --namespace production \
+            --rollback-on-failure \
+            --timeout 5m0s
+
+  - language: yaml
+    label: 'Pin Helm version to avoid flag compatibility issues'
+    code: |
+      - name: Set up Helm
+        uses: azure/setup-helm@v5
+        with:
+          version: '3.17.x'   # Use Helm 3 if --atomic is required and not yet migrated
+          # Or use Helm 4.1.1+ which restores --atomic as a deprecated alias:
+          # version: '4.1.1'
+
+      - name: Deploy chart
+        run: |
+          helm install my-release ./chart \
+            --namespace production \
+            --atomic \
+            --timeout 5m0s
+
+  - language: yaml
+    label: 'Upgrade and install combined (helm upgrade --install)'
+    code: |
+      - name: Deploy chart
+        run: |
+          # helm upgrade retains --atomic as deprecated in all Helm 4 versions.
+          # Use upgrade --install as an alternative that works across Helm 3 and 4:
+          helm upgrade --install my-release ./chart \
+            --namespace production \
+            --atomic \
+            --timeout 5m0s
+prevention:
+  - "Use `helm upgrade --install` instead of `helm install` when possible — `--atomic` was retained on upgrade in all Helm 4 versions."
+  - "Pin Helm versions with `azure/setup-helm` to avoid silent tool version changes when ubuntu-latest migrates to ubuntu-26.04."
+  - "Replace `--atomic` with `--rollback-on-failure` in new workflows — this is the Helm 4 canonical flag name."
+  - "Run `helm version` as an early step to catch unexpected version jumps before the deployment step."
+docs:
+  - url: 'https://github.com/helm/helm/issues/31900'
+    label: 'helm/helm#31900 — helm install --atomic no longer works in Helm 4'
+  - url: 'https://github.com/helm/helm/pull/31901'
+    label: 'helm/helm#31901 — fix: restore deprecated --atomic flag on install for backwards compatibility'
+  - url: 'https://helm.sh/docs/topics/v4_migration/'
+    label: 'Helm v4 Migration Guide — CLI flag renames'
+  - url: 'https://github.com/actions/runner-images/commit/9e3319d6b4acc306925295853d0ff41ddd5c40f0'
+    label: 'runner-images commit: ubuntu-26.04 installs Helm 4'

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

@@ -0,0 +1,111 @@
+id: runner-environment-218
+title: "docker/build-push-action 'load: true' and 'push: true' Are Mutually Exclusive"
+category: runner-environment
+severity: error
+tags:
+  - docker
+  - build-push-action
+  - buildx
+  - buildkit
+  - load
+  - push
+patterns:
+  - regex: 'load.{0,20}push cannot be both set|cannot use both --load and --push|load.*push.*incompatible|--load.*--push.*incompatible'
+    flags: 'i'
+  - regex: "contradictory options given: load and push"
+    flags: 'i'
+error_messages:
+  - "contradictory options given: load and push cannot be both set at the same time"
+  - "ERROR: cannot use both --load and --push flags"
+  - "error: '--load' and '--push' cannot be used together"
+  - "Error: buildx failed with: error: failed to solve: load and push cannot be both set"
+root_cause: |
+  docker/build-push-action (and the underlying docker buildx) does not support
+  setting both 'load: true' and 'push: true' in the same build step. These two
+  options are mutually exclusive:
+
+  - 'load: true' exports the built image into the local Docker daemon
+    (equivalent to --load / --output type=docker).
+  - 'push: true' pushes the image to a remote registry
+    (equivalent to --push / --output type=registry).
+
+  Both flags specify different output targets, and docker buildx cannot satisfy
+  both simultaneously with most drivers. The docker-container and kubernetes
+  drivers explicitly reject the combination. The docker driver (used without
+  explicit driver setup) may silently ignore 'push' in some versions.
+
+  Common triggers:
+  - Copying a workflow snippet that has 'push: true' and adding 'load: true'
+    for local testing without removing 'push: true'.
+  - Conditional 'push' logic using expressions that evaluate to true at the
+    same time as unconditional 'load: true'.
+fix: |
+  Use only one of 'load' or 'push' in a single step. To both test locally and
+  push to a registry, split the build into two separate steps, or use
+  conditional logic so only one output target is active at a time.
+
+  The idiomatic pattern is:
+  - Set 'push: ${{ github.ref == 'refs/heads/main' }}' to push only on
+    default branch, and omit 'load:' entirely (or use a separate step for
+    local testing).
+  - To load the image for integration tests AND push on main, build twice:
+    once with 'load: true' for tests, once with 'push: true' for release.
+  - Use build outputs caching (cache-from/cache-to) so the second build
+    is fast.
+fix_code:
+  - language: yaml
+    label: "Wrong — load and push both true (fails)"
+    code: |
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          load: true      # ❌ Incompatible with push: true
+          push: true      # ❌ Incompatible with load: true
+          tags: myrepo/myimage:latest
+
+  - language: yaml
+    label: "Fixed — push conditionally, no load"
+    code: |
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: ${{ github.ref == 'refs/heads/main' }}
+          tags: myrepo/myimage:latest
+
+  - language: yaml
+    label: "Fixed — load for tests, push separately on main"
+    code: |
+      - name: Build image for integration tests
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          load: true        # ✅ load only — no push
+          tags: myrepo/myimage:test
+
+      - name: Run integration tests
+        run: docker run --rm myrepo/myimage:test ./run-tests.sh
+
+      - name: Push to registry (main branch only)
+        if: github.ref == 'refs/heads/main'
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true        # ✅ push only — no load
+          tags: myrepo/myimage:latest
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+prevention:
+  - "Never set both 'load: true' and 'push: true' in the same build-push-action step."
+  - "Use 'push: ${{ condition }}' expression to conditionally push; omit 'load' in the same step."
+  - "If you need the image locally for testing and also want to push, use two separate steps."
+  - "Review docker/build-push-action README — the compatibility matrix for load, push, and outputs is documented."
+docs:
+  - url: "https://github.com/docker/build-push-action#inputs"
+    label: "docker/build-push-action — inputs reference (load, push, outputs)"
+  - url: "https://docs.docker.com/build/building/export/"
+    label: "Docker Buildx — build output types (load vs push)"
+  - url: "https://github.com/docker/build-push-action/blob/master/README.md#multi-platform-image"
+    label: "docker/build-push-action — multi-platform and output guidance"

package/errors/runner-environment/ubuntu-24-man-db-dpkg-trigger-apt-install-stall.yml

@@ -0,0 +1,94 @@
+id: runner-environment-207
+title: 'ubuntu-24.04 man-db dpkg trigger stalls apt-get install for minutes'
+category: runner-environment
+severity: warning
+tags:
+  - ubuntu-24.04
+  - apt-get
+  - man-db
+  - dpkg-trigger
+  - package-installation
+  - self-hosted
+patterns:
+  - regex: 'Processing triggers for man-db \('
+    flags: 'i'
+  - regex: 'man-db \(2\.1[0-9]\.[0-9]'
+    flags: 'i'
+error_messages:
+  - 'Processing triggers for man-db (2.12.0-4build2) ...'
+  - 'Processing triggers for man-db ...'
+root_cause: |
+  The `man-db` package is pre-installed on ubuntu-24.04 GitHub-hosted runner
+  images (and is commonly present on self-hosted Ubuntu 24.04 runners). When
+  any `apt-get install` step installs or upgrades a package that ships man
+  pages, the dpkg trigger for `man-db` fires automatically and rebuilds the
+  entire manual-page database.
+
+  On ubuntu-24.04 runners, this database regeneration reads and writes several
+  gigabytes of data through the runner's I/O subsystem, which is heavily
+  shared and has limited I/O resources. The trigger typically hangs the step
+  for **1–7+ minutes** even for simple package installs like `cmake` or
+  `libssl-dev`.
+
+  GitHub fixed this in hosted runner image ubuntu24/20251102.99 (November
+  2025) by removing `man-db` from the default image. However, self-hosted
+  runners on Ubuntu 24.04 that predate this fix, Docker-based container jobs
+  using ubuntu:24.04, and pinned runner image versions remain affected.
+
+  The equivalent tzdata hang (`sudo DEBIAN_FRONTEND=noninteractive apt-get ...`)
+  is a separate issue caused by interactive prompts; the man-db issue is
+  distinct — it stalls silently with no interactive prompt.
+fix: |
+  **For self-hosted runners or container jobs (manual fix):**
+
+  Add a step before package installation to remove man-db:
+
+  ```yaml
+  - name: Disable man-db trigger
+    run: sudo rm -f /var/lib/man-db/auto-update
+  ```
+
+  Or uninstall man-db entirely:
+
+  ```yaml
+  - name: Remove man-db
+    run: sudo apt-get remove -y --purge man-db 2>/dev/null || true
+  ```
+
+  **For GitHub-hosted runners:**
+  Upgrade to ubuntu-24.04 runner image version ubuntu24/20251102.99 or later.
+  The latest ubuntu-24.04 label automatically uses a fixed image.
+
+  **Minimal impact workaround (all runners):**
+  Use `DEBIAN_FRONTEND=noninteractive` — this avoids tzdata prompts but does
+  NOT prevent the man-db trigger. You must use the `rm -f /var/lib/man-db/auto-update`
+  approach to suppress the trigger.
+fix_code:
+  - language: yaml
+    label: 'Disable man-db trigger before apt-get install'
+    code: |
+      - name: Remove man-db auto-update trigger
+        run: sudo rm -f /var/lib/man-db/auto-update
+
+      - name: Install dependencies
+        run: sudo apt-get install -y cmake libssl-dev
+  - language: yaml
+    label: 'Uninstall man-db entirely (self-hosted runners)'
+    code: |
+      - name: Remove man-db (prevents dpkg trigger overhead)
+        run: sudo apt-get remove -y --purge man-db 2>/dev/null || true
+
+      - name: Install dependencies
+        run: sudo apt-get install -y cmake libssl-dev
+prevention:
+  - 'Add a man-db removal step at the top of jobs that run apt-get install on self-hosted ubuntu-24.04 runners'
+  - 'On GitHub-hosted runners, always use the current ubuntu-24.04 label (not pinned image SHAs from before November 2025)'
+  - 'For Docker container jobs, use an image that does not pre-install man-db, or add the removal step to your Dockerfile'
+  - 'Set a job-level timeout-minutes so that an unexpected man-db stall does not consume runner quota for hours'
+docs:
+  - url: 'https://github.com/actions/runner/issues/4030'
+    label: 'actions/runner#4030 — man-db trigger severely stalls apt-get on ubuntu-24.04'
+  - url: 'https://github.com/actions/runner-images/issues/10977'
+    label: 'runner-images#10977 — Disable man-db dpkg trigger (fixed in ubuntu24/20251102.99)'
+  - url: 'https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/2073797'
+    label: 'Ubuntu bug #2073797 — man-db trigger performance regression'