@htekdev/actions-debugger 1.0.117 → 1.0.118

package/errors/caching-artifacts/caching-artifacts-069.yml

@@ -0,0 +1,133 @@
+id: caching-artifacts-069
+title: 'actions/cache save@v5 "Unable to Reserve Cache" When Key Already Exists for Same Branch'
+category: caching-artifacts
+severity: warning
+tags:
+  - cache
+  - cache-save
+  - v5
+  - immutable
+  - key-exists
+  - save-only
+  - reserve-cache
+patterns:
+  - regex: 'Unable to reserve cache with key .+, another job may be creating this cache'
+    flags: 'i'
+  - regex: 'More Details: Key already reserved duplicate'
+    flags: 'i'
+  - regex: 'Failed to save: Unable to reserve cache'
+    flags: 'i'
+error_messages:
+  - 'Failed to save: Unable to reserve cache with key my-cache-key, another job may be creating this cache.'
+  - 'Warning: Cache save failed.'
+  - 'More Details: Key already reserved duplicate'
+root_cause: |
+  GitHub's cache service is write-once per key+branch combination. Once a cache entry
+  has been successfully written for a given key on a given branch/ref, that key cannot
+  be overwritten. The slot is permanently "reserved" by the first writer.
+
+  When using `actions/cache/save@v5` (the standalone save action, separate from the
+  combined restore+save `actions/cache@v5`), the action does NOT automatically skip the
+  save if an exact cache key match already exists. It attempts to write the cache, the
+  service returns "Key already reserved duplicate" (v5 API uses proper JSON errors
+  unlike v3/v4 which returned HTML DOCTYPE responses), and the action emits:
+    "Failed to save: Unable to reserve cache with key X, another job may be creating this cache."
+    "Warning: Cache save failed."
+
+  This differs from the combined `actions/cache@v5` which checks the CACHE_HIT output
+  from its restore step and automatically skips the save on an exact key match. When
+  using the split restore/save pattern (actions/cache/restore + actions/cache/save),
+  the save action has no restore step context, so it always attempts to write —
+  triggering this warning when the key already exists from a previous workflow run.
+
+  Common trigger scenarios:
+  - Using actions/cache/save@v5 in an always() post step to save a cache built during
+    the job, on the second+ run of the same workflow on the same branch
+  - Using @actions/cache npm package's saveCache() directly without first checking
+    whether the key was already restored (restoreCache returned an exact match)
+  - Parallel jobs on the same branch all attempting to save under the same static key
+fix: |
+  Option 1 (recommended): Gate the save step on cache-miss.
+  Use actions/cache/restore@v5 first and only run the save step when the primary key
+  was not an exact hit:
+
+    - name: Restore cache
+      id: restore
+      uses: actions/cache/restore@v5
+      with:
+        key: ${{ env.CACHE_KEY }}
+        path: ~/.cache/my-tool
+
+    - name: Build
+      run: make build
+
+    - name: Save cache
+      if: steps.restore.outputs.cache-hit != 'true'
+      uses: actions/cache/save@v5
+      with:
+        key: ${{ env.CACHE_KEY }}
+        path: ~/.cache/my-tool
+
+  Option 2: Use the combined actions/cache@v5 which handles this automatically.
+
+  Option 3 (programmatic): If using @actions/cache npm package, check restoreCache
+  return value before calling saveCache — skip save if the return value matches the
+  primary key (exact hit).
+fix_code:
+  - language: yaml
+    label: 'Option 1 — gate save on cache-miss from restore step'
+    code: |
+      steps:
+        - name: Restore cache
+          id: cache-restore
+          uses: actions/cache/restore@v5
+          with:
+            key: ${{ runner.os }}-build-${{ hashFiles('**/lockfiles') }}
+            restore-keys: |
+              ${{ runner.os }}-build-
+            path: |
+              ~/.cache/my-tool
+              node_modules
+
+        - name: Build
+          run: make all
+
+        # Only save when the primary key was not an exact hit
+        - name: Save cache
+          if: steps.cache-restore.outputs.cache-hit != 'true'
+          uses: actions/cache/save@v5
+          with:
+            key: ${{ runner.os }}-build-${{ hashFiles('**/lockfiles') }}
+            path: |
+              ~/.cache/my-tool
+              node_modules
+  - language: yaml
+    label: 'Option 2 — use combined cache action (auto-skips save on exact hit)'
+    code: |
+      steps:
+        - name: Cache dependencies
+          uses: actions/cache@v5
+          with:
+            key: ${{ runner.os }}-build-${{ hashFiles('**/lockfiles') }}
+            restore-keys: |
+              ${{ runner.os }}-build-
+            path: |
+              ~/.cache/my-tool
+              node_modules
+prevention:
+  - 'Prefer the combined actions/cache@v5 over split restore/save when the primary key
+    is static or content-hash-based — the combined action skips save on exact hit automatically'
+  - 'When using split restore/save, always gate the save step with
+    if: steps.<restore-id>.outputs.cache-hit != ''true'''
+  - 'Never treat "Warning: Cache save failed." as a hard error when using static cache keys
+    across repeated runs — add continue-on-error: true to the save step if the warning
+    is expected and the restored cache is already valid'
+  - 'For programmatic use via @actions/cache npm package, check the return value of
+    restoreCache() before calling saveCache() — skip save when result === primaryKey'
+docs:
+  - url: 'https://github.com/actions/cache/issues/1707'
+    label: 'actions/cache#1707 — Unable to reserve cache (actions/cache/save@v5)'
+  - url: 'https://github.com/actions/cache/tree/main/save#readme'
+    label: 'actions/cache save action README — Case 1: reuse key as-is'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows'
+    label: 'GitHub Docs — Caching dependencies to speed up workflows'

package/errors/concurrency-timing/workflow-run-head-branch-null-schedule-dispatch-concurrency.yml

@@ -0,0 +1,135 @@
+id: concurrency-timing-055
+title: '`github.event.workflow_run.head_branch` is null for `schedule`- and `workflow_dispatch`-triggered
+  parent workflows — concurrency group key collapses all downstream runs into one slot'
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - workflow_run
+  - concurrency
+  - head_branch
+  - schedule
+  - null-key
+  - deployment
+patterns:
+  - regex: 'on:\s+workflow_run:'
+    flags: 'si'
+  - regex: 'group:.*event\.workflow_run\.head_branch'
+    flags: 'i'
+error_messages:
+  - "Canceling since a higher priority waiting run was found for the same concurrency group"
+  - "This run has been cancelled. Concurrency group: deploy-"
+root_cause: |
+  `github.event.workflow_run.head_branch` is null/empty when the triggering (upstream)
+  workflow was itself triggered by `schedule`, `workflow_dispatch`, `repository_dispatch`,
+  or any other non-branch event. Only workflows triggered by branch-based events (push,
+  pull_request, etc.) produce a non-null head_branch value.
+
+  The standard recommendation for workflow_run-triggered workflows (see also
+  concurrency-timing-045) is to key the concurrency group on head_branch:
+
+      concurrency:
+        group: deploy-${{ github.event.workflow_run.head_branch }}
+
+  For branch-based parent triggers this works correctly. For schedule- or
+  workflow_dispatch-triggered parent workflows, head_branch is null, making the
+  concurrency group key evaluate to `deploy-` (empty suffix). Every downstream run
+  where the parent was triggered by schedule or dispatch shares the SAME concurrency
+  slot. The second scheduled downstream run cancels the first — silently, because
+  `${{ null }}` evaluates to an empty string in GitHub Actions expressions with no
+  warning or error.
+
+  This is commonly introduced when teams follow a deploy-after-CI pattern where the
+  nightly build (schedule) triggers a downstream deploy/notify workflow_run workflow
+  and copy the branch-scoped concurrency pattern from another workflow.
+fix: |
+  Add a fallback value to handle null head_branch, or use a more robust key.
+
+  Option 1 — head_branch with workflow_run.id fallback (recommended):
+    Use head_branch when available (branch-based parent) and fall back to the unique
+    workflow_run id (schedule/dispatch parent) to guarantee no cross-run collisions.
+
+  Option 2 — workflow_run.id only:
+    If the workflow_run-triggered downstream workflow is exclusively for non-branch
+    parents (schedule, dispatch), key the group on github.event.workflow_run.id.
+    Every downstream run gets its own unique slot.
+
+  Option 3 — Restrict trigger with branches: filter:
+    Limit the workflow_run trigger to branch-based parent runs using `branches:`.
+    Schedule/dispatch-triggered completions are silently ignored so there is no
+    concurrency collision to manage.
+fix_code:
+  - language: yaml
+    label: 'WRONG — head_branch is null for schedule-triggered parents; all runs share one slot'
+    code: |
+      on:
+        workflow_run:
+          workflows: ["Nightly Build"]
+          types: [completed]
+
+      concurrency:
+        group: deploy-${{ github.event.workflow_run.head_branch }}
+        cancel-in-progress: true
+
+      jobs:
+        deploy:
+          if: github.event.workflow_run.conclusion == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying..."
+  - language: yaml
+    label: 'RIGHT — fallback to workflow_run.id prevents slot collision for schedule parents'
+    code: |
+      on:
+        workflow_run:
+          workflows: ["Nightly Build"]
+          types: [completed]
+
+      # head_branch is populated for push/pull_request-triggered parents
+      # workflow_run.id is always unique — prevents cross-run collision for schedule/dispatch parents
+      concurrency:
+        group: deploy-${{ github.event.workflow_run.head_branch || github.event.workflow_run.id }}
+        cancel-in-progress: true
+
+      jobs:
+        deploy:
+          if: github.event.workflow_run.conclusion == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying commit ${{ github.event.workflow_run.head_sha }}"
+  - language: yaml
+    label: 'RIGHT — restrict workflow_run to branch-based parents only'
+    code: |
+      on:
+        workflow_run:
+          workflows: ["CI"]
+          types: [completed]
+          branches: [main, 'release/**']
+          # schedule- and workflow_dispatch-triggered parent completions have no branch;
+          # the branches: filter excludes them, so no null head_branch issue
+
+      concurrency:
+        group: deploy-${{ github.event.workflow_run.head_branch }}
+        cancel-in-progress: true
+
+      jobs:
+        deploy:
+          if: github.event.workflow_run.conclusion == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Deploying branch ${{ github.event.workflow_run.head_branch }}"
+prevention:
+  - 'Always check whether parent workflows may be triggered by schedule or workflow_dispatch before
+    keying a workflow_run downstream concurrency group on head_branch.'
+  - 'Add a || fallback for any workflow_run context property that may be null — head_branch, head_sha,
+    and pull_requests are null for schedule/dispatch-triggered parents.'
+  - 'Add a debug step that echoes github.event.workflow_run.head_branch early in the workflow to verify
+    it is populated for all expected parent trigger types during initial rollout.'
+  - 'Use branches: on the workflow_run trigger to restrict to branch-based events if schedule/dispatch
+    parent completions do not need to be handled.'
+docs:
+  - url: 'https://docs.github.com/en/webhooks/webhook-events-and-payloads#workflow_run'
+    label: 'GitHub Webhook Docs: workflow_run payload — head_branch property'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run'
+    label: 'GitHub Docs: workflow_run event trigger'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency'
+    label: 'GitHub Docs: Using concurrency'

package/errors/known-unsolved/node-action-post-step-wrong-inputs-nested-composite.yml

@@ -0,0 +1,133 @@
+id: known-unsolved-066
+title: 'Node Action Post Step Receives Wrong INPUT_* Env Vars When Called Through Nested Composite Action'
+category: known-unsolved
+severity: error
+tags:
+  - composite-actions
+  - post-step
+  - node-action
+  - nested
+  - inputs
+  - runner-bug
+  - savestate
+patterns:
+  - regex: 'Input required and not supplied:\s*\S+'
+    flags: 'i'
+  - regex: 'Post job cleanup\.\s*\n.*Input required'
+    flags: 'im'
+  - regex: 'post.*wrong.*input|INPUT_.*post.*ancestor'
+    flags: 'i'
+error_messages:
+  - 'Input required and not supplied: token'
+  - 'Input required and not supplied: test'
+  - 'Error: Input required and not supplied: <input-name>'
+  - 'Post job cleanup.'
+root_cause: |
+  Runner bug (actions/runner#3514, actions/runner#2030, open since 2022): when a Node.js
+  action that has a `post:` step is invoked through one or more composite action layers,
+  the runner restores the wrong `INPUT_*` environment variables for the post step execution.
+
+  At post-step execution time, the runner sets environment variables from the nearest
+  ancestor composite action's inputs, not from the inputs actually passed to the Node
+  action itself. For example:
+
+    Workflow → outer-composite (inputs: image-tag: "foo") → inner-composite
+      → node-action (inputs: image-tag: "foo")
+
+  The node action's main step correctly sees INPUT_IMAGE_TAG=foo.
+  In the post step, INPUT_IMAGE_TAG is absent or overwritten by the outer composite's
+  INPUT_IMAGE_TAG value (or another ancestor composite's value), causing:
+  - Required inputs to appear missing → visible error in post cleanup
+  - Optional inputs to resolve to wrong values → silent wrong behavior (e.g.,
+    devcontainers/ci pushes image with wrong tag; codeql-action uploads SARIF with
+    wrong token)
+
+  This affects ANY Node action with a post step that is called through composite
+  action nesting (depth ≥ 2). First-party actions affected include github/codeql-action
+  (fixed via workaround in codeql-action#2557) and pnpm/action-setup (issue #253).
+fix: |
+  GitHub has not fixed the runner bug. The canonical workaround is to persist inputs
+  in the action's main step using `core.saveState()` and read them back in the post
+  step using `core.getState()` instead of `core.getInput()`.
+
+  Actions consuming this workaround pattern:
+  - github/codeql-action (PR #2557): saveState for upload inputs
+  - Any action that reads inputs in its post step
+
+  If you maintain a Node action with a post step, add to your main.ts:
+    core.saveState('my-input', core.getInput('my-input'));
+  And in your post.ts:
+    const val = core.getState('my-input');  // use this instead of core.getInput
+
+  If you are a workflow author calling a third-party action through composite layers
+  and seeing wrong post-step behavior, check whether the action uses `core.getInput`
+  in its post step. If so, file an issue with the action maintainer referencing
+  actions/runner#3514 and the saveState workaround.
+fix_code:
+  - language: typescript
+    label: 'Action main.ts — persist inputs to state before post step runs'
+    code: |
+      import * as core from '@actions/core';
+
+      async function run() {
+        // Read inputs normally in main
+        const token = core.getInput('token', { required: true });
+        const imageName = core.getInput('image-name');
+
+        // Persist for post step (workaround for runner#3514)
+        core.saveState('token', token);
+        core.saveState('image-name', imageName);
+
+        // ... rest of main logic
+      }
+
+      run();
+  - language: typescript
+    label: 'Action post.ts — read from state, NOT core.getInput'
+    code: |
+      import * as core from '@actions/core';
+
+      async function runPost() {
+        // Use getState, NOT getInput — inputs are wrong in post step
+        // when called through nested composite action (runner#3514)
+        const token = core.getState('token');
+        const imageName = core.getState('image-name');
+
+        // ... post step logic using state values
+      }
+
+      runPost();
+  - language: yaml
+    label: 'action.yml — declare post step'
+    code: |
+      name: 'My Action'
+      inputs:
+        token:
+          required: true
+        image-name:
+          required: false
+      runs:
+        using: 'node20'
+        main: 'dist/main.js'
+        post: 'dist/post.js'
+        post-if: always()
+prevention:
+  - 'In any Node action with a post: step, always use core.saveState/core.getState for
+    inputs consumed in post, never core.getInput — this is defensive programming regardless
+    of nesting depth'
+  - 'Test your action in a composite action wrapper (at least 2 layers deep) to catch
+    this bug before publishing'
+  - 'Check release notes of actions/runner for fixes to this bug before assuming
+    the built-in behavior is fixed'
+  - 'When using actions with known post-step input bugs through composite layers,
+    consider calling them directly from the workflow (not nested in a composite) as
+    a temporary workaround'
+docs:
+  - url: 'https://github.com/actions/runner/issues/3514'
+    label: 'actions/runner#3514 — Wrong environment passed to node post when called by composite called by composite'
+  - url: 'https://github.com/actions/runner/issues/2030'
+    label: 'actions/runner#2030 — Composite: Nested actions post steps have the wrong context (open since 2022)'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#sending-values-to-the-pre-and-post-actions'
+    label: 'GitHub Docs — Sending values to pre and post actions (saveState/getState)'
+  - url: 'https://github.com/github/codeql-action/pull/2557'
+    label: 'codeql-action#2557 — Fix: persist inputs between upload action and post step (reference implementation)'

package/errors/known-unsolved/ubuntu-24-04-arm64-missing-binder-ashmem-kernel-modules.yml

@@ -0,0 +1,149 @@
+id: known-unsolved-065
+title: 'ubuntu-24.04-arm64 Hosted Runner Kernel Missing binder_linux and ashmem_linux Modules — Android Container Tests Fail'
+category: known-unsolved
+severity: limitation
+tags:
+  - ubuntu-24.04-arm64
+  - arm64
+  - kernel-modules
+  - android
+  - binder
+  - ashmem
+  - container
+  - known-limitation
+patterns:
+  - regex: 'modprobe: FATAL: Module binder_linux not found|modprobe.*binder_linux.*not found'
+    flags: 'i'
+  - regex: 'modprobe: FATAL: Module ashmem_linux not found|modprobe.*ashmem_linux.*not found'
+    flags: 'i'
+  - regex: '/dev/binder: No such file or directory|/dev/ashmem: No such file or directory'
+    flags: 'i'
+  - regex: 'CONFIG_ANDROID_BINDER_IPC.*not set|binder_linux.*absent.*kernel'
+    flags: 'i'
+error_messages:
+  - 'modprobe: FATAL: Module binder_linux not found in directory /lib/modules/<kernel>'
+  - 'modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/<kernel>'
+  - '/dev/binder: No such file or directory'
+  - '/dev/ashmem: No such file or directory'
+  - 'modprobe binder_linux exited with code 1'
+root_cause: |
+  The ubuntu-24.04-arm64 GitHub Actions hosted runner kernel is compiled WITHOUT
+  `CONFIG_ANDROID_BINDER_IPC=m` and `CONFIG_ANDROID_BINDERFS=m`. This means the
+  `binder_linux` and `ashmem_linux` kernel modules do not exist in
+  `/lib/modules/$(uname -r)/` on ARM64 runners.
+
+  Attempting `modprobe binder_linux` fails silently (exits 1) on ARM64 because
+  the module is simply absent from the kernel tree — it cannot be loaded even
+  as a privileged container.
+
+  **Why x86_64 hosted runners DO have these modules:**
+  The x86_64 ubuntu-24.04 hosted runners expose `binder` and `ashmem` because
+  they support the [GitHub Actions KVM Android hardware acceleration feature](https://github.blog/changelog/2024-04-02-github-actions-hardware-accelerated-android-virtualization-now-available/)
+  (released April 2024). The x86_64 kernel was explicitly built with Android
+  IPC support to enable this feature. The ARM64 kernel image is compiled
+  separately and was not built with these modules.
+
+  **Affected use cases:**
+  - Running [ReDroid](https://github.com/remote-android/redroid-doc) (GPU-enabled
+    Android-in-Docker) on native ARM64 CI for ARM-native app testing
+  - Running [Waydroid](https://waydro.id/) in ARM64 CI containers
+  - Any workflow that requires `/dev/binder` or `/dev/ashmem` devices
+
+  **Confirmed on:**
+  - ubuntu-24.04-arm64 image 20260531.15.1 (kernel aarch64, Azure westus2)
+  - Source: actions/runner-images#14184 (feature request, June 2026, open)
+
+  **No current workaround exists** — the module cannot be compiled from source
+  against the runner's kernel headers without the kernel source tree, and the
+  azure-linux kernel for ARM64 is not shipped with headers for out-of-tree
+  `binder_linux` builds. A request to add the modules to the ubuntu-24.04-arm64
+  image is tracked at runner-images#14184 and is currently open with no ETA.
+fix: |
+  **No complete fix is currently available for native ARM64 hosted runners.**
+
+  **Option 1 (Recommended): Use ubuntu-24.04 x86_64 runners for Android tests**
+
+  The x86_64 ubuntu-24.04 runner has `binder_linux` and `ashmem_linux` and
+  supports Android container tests via KVM acceleration. ARM-native testing can
+  be approximated via the Android native bridge, at the cost of some overhead:
+
+  ```yaml
+  android-test:
+    runs-on: ubuntu-24.04   # x86_64 — has binder_linux/ashmem_linux
+    steps:
+      - uses: actions/checkout@v6
+      - run: |
+          sudo modprobe binder_linux  # succeeds on x86_64
+          sudo modprobe ashmem_linux
+          # ... run ReDroid or Waydroid Android container tests
+  ```
+
+  **Option 2: Use real ARM hardware (Firebase Test Lab, self-hosted)**
+
+  For true ARM64 profiling (power/wakelock, native execution) use Firebase
+  Test Lab with physical Pixel hardware, or a self-hosted ARM64 runner on
+  hardware/VMs that expose binder devices.
+
+  **Option 3: Compile binder_linux from source (complex, unreliable)**
+
+  Without kernel headers matching the runner kernel, this is not practical
+  on GitHub-hosted runners.
+
+  **Track for a platform fix:** Follow actions/runner-images#14184 for progress
+  on adding `binder_linux`/`ashmem_linux` to the ubuntu-24.04-arm64 runner image.
+fix_code:
+  - language: yaml
+    label: 'Route Android container tests to x86_64 runner which has binder_linux/ashmem_linux'
+    code: |
+      jobs:
+        android-container-test:
+          # ubuntu-24.04-arm64 runner kernel is compiled without CONFIG_ANDROID_BINDER_IPC=m
+          # Use x86_64 runner which has binder_linux/ashmem_linux for KVM Android acceleration.
+          # Track runner-images#14184 for ARM64 kernel module support.
+          runs-on: ubuntu-24.04     # x86_64 — binder_linux available
+          container:
+            image: redroid/redroid:15.0.0-latest
+            options: --privileged
+          steps:
+            - uses: actions/checkout@v6
+            - name: Verify binder device
+              run: ls -la /dev/binder /dev/ashmem
+            - name: Run instrumented tests
+              run: ./gradlew connectedAndroidTest
+  - language: yaml
+    label: 'Guard ARM64 jobs against missing kernel modules'
+    code: |
+      jobs:
+        android-test:
+          runs-on: ${{ matrix.runner }}
+          strategy:
+            matrix:
+              runner: [ubuntu-24.04, ubuntu-24.04-arm64]
+          steps:
+            - uses: actions/checkout@v6
+            - name: Check binder_linux availability
+              id: binder-check
+              run: |
+                if modprobe binder_linux 2>/dev/null; then
+                  echo "available=true" >> "$GITHUB_OUTPUT"
+                else
+                  echo "available=false" >> "$GITHUB_OUTPUT"
+                  echo "::warning::binder_linux not available on $(uname -m) runner. Skipping Android container tests."
+                fi
+            - name: Run Android container tests
+              if: steps.binder-check.outputs.available == 'true'
+              run: ./run-android-tests.sh
+prevention:
+  - 'Do not assume binder_linux or ashmem_linux are available on ubuntu-24.04-arm64 hosted runners — the kernel was not built with CONFIG_ANDROID_BINDER_IPC=m.'
+  - 'Route Android container (ReDroid/Waydroid) CI tests to x86_64 ubuntu-24.04 runners until runner-images#14184 is resolved.'
+  - 'Always guard binder_linux/ashmem_linux modprobe calls with an availability check so ARM64 jobs fail gracefully rather than unexpectedly.'
+  - 'Track the ARM64 runner image feature request at actions/runner-images#14184 to know when the modules are added.'
+docs:
+  - url: 'https://github.com/actions/runner-images/issues/14184'
+    label: 'runner-images #14184 — Add binder_linux and ashmem_linux kernel modules to ubuntu-24.04-arm image (open Jun 2026)'
+  - url: 'https://github.com/remote-android/redroid-doc/issues/928'
+    label: 'redroid-doc #928 — GitHub Actions ubuntu-24.04-arm runners lack binder/ashmem kernel modules'
+  - url: 'https://github.blog/changelog/2024-04-02-github-actions-hardware-accelerated-android-virtualization-now-available/'
+    label: 'GitHub Changelog — Hardware-accelerated Android virtualization on x86_64 Actions runners'
+  - url: 'https://github.com/actions/runner-images/releases/tag/ubuntu24-arm64%2F20260531.15'
+    label: 'ubuntu-24.04-arm64 image 20260531.15.1 release notes'