Upgrade all GitHub Actions to Node 24-native releases (eliminate Node 20 deprecation warnings)

[acoliver]

Summary

GitHub Actions continues to emit Node.js 20 deprecation warnings on our workflow runs. The warning explicitly names actions that are pinned to SHAs built against the Node 20 runtime:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02, oven-sh/setup-bun@735343b667d3e6f658f44d0eca948eb6282f2b76.

This is separate from (but related to) issue #2015, which tracks the project's own Node runtime baseline. The project runtime is already on Node 24 (.nvmrc = 24, package.json engines >= 24, Dockerfile node:24-slim). The remaining problem is that third-party GitHub Actions are still pinned to versions compiled against Node 20.

Issue #2316 attempted this for milestone 0.10.0 but was closed incomplete — the deprecation warnings are still firing.

Reference: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

Root Cause

The ratchet pinning system freezes each action to a specific SHA. Several of those SHAs point to action releases whose action.yml declares node20 as the runtime. GitHub now force-runs them on Node 24 but emits a deprecation warning each time. The fix is to re-pin every action to a release that ships node24 (or node24 wrapper) natively.

Complete Catalog of Actions Needing Upgrade

Explicitly Called Out in the Deprecation Warning

Action	Pinned SHA	Ratchet Tag	Latest Release	Affected Workflows
actions/upload-artifact	ea165f8d	v4	v7.0.1	ci.yml (3 uses), _evals-run.yml, interactive-ui.yml, luther.yml, nightly.yml (2 uses), ocr-review.yml
oven-sh/setup-bun	735343b6	v2	v2.2.0	ci.yml (7 uses), e2e.yml (2 uses), _evals-run.yml, build-sandbox.yml, interactive-ui.yml, luther.yml, nightly.yml (3 uses), release.yml, smoke-test.yml

Other Actions Behind Latest (Need Re-pinning via Ratchet)

Action	Current Pinned Tag	Latest Release	Affected Workflows	Notes
actions/checkout	v5 (SHA 08c6903c), v5 (SHA 08eba0b2 in e2e), v4 (SHA 11bd7190 in release/pr-triage), v4.3.0 (SHA 08eba0b1 in upstream-sync)	v7.0.1	all workflows	3+ different SHAs for the same action across workflows — must be unified
actions/download-artifact	v5 (SHA 634f93cb) in ci/evals, v4 (SHA d3f86a10) in ocr-review	v8.0.1	ci.yml, evals-nightly.yml, ocr-review.yml	Version inconsistency between workflows
actions/setup-node	v6 (SHA 48b55a0)	v7.0.0	17 uses across all workflows
actions/cache	v4 (SHA 0057852b)	v6.1.0	ci.yml (3 uses)
actions/setup-python	v5 (SHA a26af69)	v7.0.0	ci.yml
actions/create-github-app-token	v2.0.6 (SHA df432cee)	v3.2.0	luther.yml (commented out)
github/codeql-action	v3.29.9 (SHA df559355)	codeql-bundle-v2.26.1 (v3 line)	ci.yml (init + analyze)
docker/setup-buildx-action	v3 (SHA e468171)	v4.2.0	build-sandbox.yml, e2e.yml
docker/login-action	v3.3.0 (SHA 9780b0c)	v4.4.0	build-sandbox.yml
docker/metadata-action	v5.5.1 (SHA 8e5442c)	v6.2.0	build-sandbox.yml
docker/build-push-action	v6.9.0 (SHA 4f58ea7)	v7.3.0	build-sandbox.yml
dorny/test-reporter	v2.1.1 (SHA dc3a926)	v3.0.0	ci.yml	Major version bump — verify breaking changes
fkirc/skip-duplicate-actions	v5.3.1 (SHA f75f66c)	v5.3.2	ci.yml, e2e.yml	Minor patch
sethvargo/ratchet	v0.11.4 (SHA 8b4ca25)	v0.12.0	ci.yml	Used by the pinning system itself
actions/github-script	SHA f28e40c (v9.x)	v9.0.0	(check usage)	Verify if already current

Already Current

Action	Pinned	Latest	Status
thollander/actions-comment-pull-request	v3.0.1	v3.0.1	OK

Additional Inconsistencies Found

1. actions/checkout has 4 different pinned SHAs across workflows:

   • 08c6903c (v5) — most workflows
   • 08eba0b2 (v5, different commit!) — e2e.yml
   • 11bd7190 (v4) — release.yml, llxprt-scheduled-pr-triage.yml
   • 08eba0b1 (v4.3.0, invalid SHA?) — upstream-sync.yml

2. actions/download-artifact has 2 different major versions (v4 and v5) across workflows.

3. Some workflows lack ratchet comments entirely:

   • smoke-test.yml — no ratchet comment on checkout
   • release.yml — uses bare # v4 not ratchet format
   • upstream-sync.yml — uses # v4.3.0 not ratchet format
   • llxprt-scheduled-pr-triage.yml — uses bare # v4 not ratchet format

Proposed Work

1. Run ratchet to re-pin all actions to their latest Node-24-native releases:

   • ratchet pin .github/workflows/*.yml .github/actions/**/*.yml
   • This will update all SHAs to the latest tag for each ratcheted action
   • For actions without ratchet comments, add them first

2. Fix the checkout version inconsistencies — unify all workflows to the same SHA/tag.

3. Fix the download-artifact version split — upgrade ocr-review.yml from v4 to match the rest.

4. Add ratchet comments to workflows missing them (smoke-test.yml, release.yml, upstream-sync.yml, llxprt-scheduled-pr-triage.yml).

5. Verify major-version upgrade breaking changes:

   • actions/upload-artifact v4 to v7 (v5 changed artifact IDs, v6/v7 may have further changes)
   • actions/download-artifact v4/v5 to v8
   • dorny/test-reporter v2 to v3
   • docker/* v3/v5/v6 to v4/v6/v7

6. Test all workflows after re-pinning to confirm:

   • No Node 20 deprecation warnings
   • All CI jobs still pass (test, lint, typecheck, format, build)
   • E2E tests pass
   • Nightly/smoke/release workflows function correctly

Acceptance Criteria

• All GitHub Actions workflows run without Node.js 20 deprecation warnings
• Every action is pinned (via ratchet) to a release that uses the Node 24 runtime natively
• No action has inconsistent SHAs across workflows (same action = same SHA everywhere)
• All workflows have proper ratchet comments
• Full CI suite passes: test, lint, typecheck, format, build, e2e
• Nightly and release smoke workflows verified

Context

• Related: Update Node.js minimum version to Node 24 #2015 (project Node runtime baseline — already on Node 24)
• Related: Upgrade CI workflows to Node 24 runtime #2316 (prior attempt, closed incomplete)
• Deprecation notice: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
• Actions runner migration PR: Node 20 -> Node 24 migration feature flagging, opt-in and opt-out environment variables actions/runner#3948

[coderabbitai]

🔗 Related PRs

#814 - fix: Pin release workflow to ubuntu-22.04 for sharp/libspng compatibility #812 [merged]
#1832 - Bootstrap release workflow dependencies in both paths (Fixes #1831) [merged]
#1858 - fix(ci): update GitHub Actions to valid commit SHAs in evals-nightly.yml (Fixes #1857) [merged]
#2096 - Enforce ESLint guardrails (Fixes #2079, Fixes #2080) [merged]
#2318 - Upgrade CI workflows and runtime baseline to Node 24 (Fixes #2316) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Normalize every third-party action reference to the standard trailing # ratchet: comment format and unify divergent pins (especially the four actions/checkout SHAs and the split download-artifact versions) so a single ratchet pass manages everything.
• Upgrade by editing each ratchet comment tag to its Node-24-native target version and then running the ratchet CLI to resolve immutable SHAs — since ratchet pins to the tag in the comment rather than auto-discovering new majors.
• Verify major-version breaking changes with focused attention on the evals aggregation pipeline (the only consumer that depends on artifact download layout), then validate the full CI/E2E/nightly/release surface for zero Node 20 warnings and green builds.

Design Choices

Design Choice 1: How should ratchet be driven to actually upgrade major versions?

Options Considered:

1. Manually edit each # ratchet: comment tag to the desired target major/version, then run ratchet pin to resolve the corresponding SHA (ratchet's supported update flow).
2. Delete the SHAs and let ratchet re-pin from scratch (still requires the target tag in the comment; same manual tag-editing step).

Chosen Option: 1

Rationale: Editing the comment tag then running ratchet pin is ratchet's intended upgrade mechanism and gives explicit, reviewable control over which version each action moves to.

Design Choice 2: Which target version should each action be pinned to?

Options Considered:

1. Bump each action to the latest stable major listed in the ticket (checkout v7, upload-artifact v7, download-artifact v8, setup-node v7, etc.).
2. Bump only to the minimum Node-24-native release for each action (e.g., upload-artifact v6, download-artifact v5).

Chosen Option: 1

Rationale: The ticket explicitly targets latest releases and requires consistency; choosing latest stable also resolves the pre-existing version-drift/inconsistency acceptance criteria in one pass. (Where the ticket cites a version that appears to be docs-ahead-of-release, the latest actually-published tag should be used and noted.)

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Normalize and unify action pin comments

Bring every third-party action reference into the standard trailing # ratchet:owner/repo@version format and eliminate SHA/version drift, so that a single subsequent ratchet run can manage and re-pin everything uniformly. This phase changes only comment format and unifies which tag each file targets — it establishes a clean, ratchet-managed baseline before version bumps.

Task 1: Convert all non-standard and missing pin comments to ratchet format

Ensure every uses: line is ratchet-managed so nothing is skipped by the re-pin step.

• Add a trailing # ratchet:actions/checkout@<tag> comment to .github/workflows/smoke-test.yml (currently no comment).
• Convert bare version comments to ratchet format in .github/workflows/release.yml (# v4), .github/workflows/upstream-sync.yml (# v4.3.0), and .github/workflows/llxprt-scheduled-pr-triage.yml (# v4, including the commented-out actions/create-github-app-token line).
• Convert bare # v3.0.1 comments for thollander/actions-comment-pull-request in .github/workflows/pr-review.yml and .github/actions/post-coverage-comment/action.yml to ratchet format.
• Convert the comment-above-line style for fkirc/skip-duplicate-actions in .github/workflows/ci.yml and .github/workflows/e2e.yml to the standard trailing-comment style.

Task 2: Unify divergent SHAs/versions for the same action

Satisfy the acceptance criterion that a given action uses the same SHA/tag everywhere.

• Standardize actions/checkout to a single target tag across all workflows, replacing the four divergent pins (08c6903c/v5, 08eba0b2/v5 in e2e.yml, 11bd7190/v4 in release.yml and llxprt-scheduled-pr-triage.yml, 08eba0b1/v4.3.0 in upstream-sync.yml).
• Standardize actions/download-artifact to a single target tag, replacing the v4 pin in .github/workflows/ocr-review.yml so it matches ci.yml/evals-nightly.yml.
• Leave SHAs to be resolved by ratchet in Phase 2; in this phase only the # ratchet: tag values need to be made consistent.

🤖 Prompt for AI agents

Implement Phase 1: normalize all third-party GitHub Action pin comments to the
standard trailing `# ratchet:owner/repo@version` format and unify divergent
SHAs/tags for the same action across workflow files, establishing a clean
baseline for the ratchet CLI in Phase 2.

Steps:
- For every `uses:` line lacking a proper trailing ratchet comment, add one in
the standard `# ratchet:owner/repo@version` format:
- `.github/workflows/smoke-test.yml`: add `# ratchet:actions/checkout@<tag>`
(currently has no comment).
- `.github/workflows/release.yml`: convert bare `# v4` comment to ratchet
format.
- `.github/workflows/upstream-sync.yml`: convert bare `# v4.3.0` comment to
ratchet format.
- `.github/workflows/llxprt-scheduled-pr-triage.yml`: convert bare `# v4`
comments to ratchet format, including the commented-out
`actions/create-github-app-token` line.
- `.github/workflows/pr-review.yml` and
`.github/actions/post-coverage-comment/action.yml`: convert bare `# v3.0.1`
comments for `thollander/actions-comment-pull-request` to ratchet format.
- `.github/workflows/ci.yml` and `.github/workflows/e2e.yml`: convert the
comment-above-line style for `fkirc/skip-duplicate-actions` to the standard
trailing-comment style.
- Unify divergent SHAs/tags for the same logical action across files:
- `actions/checkout`: pick one target tag and replace all four divergent pins
(`08c6903c`/v5 and `08eba0b2`/v5 in `e2e.yml`; `11bd7190`/v4 in `release.yml`
and `llxprt-scheduled-pr-triage.yml`; `08eba0b1`/v4.3.0 in `upstream-sync.yml`)
so they reference the same tag.
- `actions/download-artifact`: pick one target tag and replace the v4 pin in
`.github/workflows/ocr-review.yml` so it matches the tag used in
`ci.yml`/`evals-nightly.yml`.
- In this phase, only make the `# ratchet:` tag values consistent — do not
resolve or change SHAs yet; SHA resolution happens via the ratchet CLI in Phase
2.

Phase 2: Set target versions and re-pin via ratchet

Update each ratchet comment tag to the chosen Node-24-native target version, then resolve all SHAs with the ratchet CLI so every action points at a Node 24 release. This is the core change that eliminates the deprecation warnings.

Task 1: Update ratchet comment tags to Node-24-native target versions

Record the intended upgrade for every action so ratchet resolves the correct SHA.

• Update comment tags for the two explicitly-warned actions: actions/upload-artifact (v4 → latest published, targeting v7 per ticket) and oven-sh/setup-bun (re-pin to latest v2 release that ships Node 24).
• Update comment tags for the remaining behind-latest actions across the affected files: actions/checkout → v7, actions/download-artifact → v8, actions/setup-node → v7, actions/cache → v6, actions/setup-python → v7, actions/create-github-app-token → v3, github/codeql-action (init + analyze) → latest v3 line, docker/setup-buildx-action → v4, docker/login-action → v4, docker/metadata-action → v6, docker/build-push-action → v7, dorny/test-reporter → v3, fkirc/skip-duplicate-actions → v5.3.2, sethvargo/ratchet → v0.12.0.
• Verify actions/github-script and thollander/actions-comment-pull-request are already at their target and adjust the tag only if needed.

Task 2: Resolve SHAs by running the ratchet CLI locally

Produce the immutable SHA pins matching the updated tags.

• Install the ratchet CLI locally (not provisioned by scripts/setup-linters.sh) and run ratchet pin against .github/workflows/*.yml and .github/actions/**/*.yml.
• Confirm every uses: line now has a 40-char SHA whose comment tag matches the target, and that identical actions resolve to identical SHAs across all files.
• Ensure the sethvargo/ratchet action reference in ci.yml's lint_github_actions job is itself re-pinned to the new v0.12.0 SHA so CI validation uses the upgraded tool.

🤖 Prompt for AI agents

Implement Phase 2: update ratchet comment tags to the chosen Node-24-native
target versions for every third-party action, then run the ratchet CLI to
resolve the immutable SHAs, which is the core change eliminating the Node 20
deprecation warnings.

Steps:
- Update the `# ratchet:` comment tag (not the SHA) for each action to its
target version:
  - `actions/upload-artifact`: v4 → latest published, targeting v7 per ticket.
  - `oven-sh/setup-bun`: re-pin to latest v2 release that ships Node 24.
  - `actions/checkout` → v7.
  - `actions/download-artifact` → v8.
  - `actions/setup-node` → v7.
  - `actions/cache` → v6.
  - `actions/setup-python` → v7.
  - `actions/create-github-app-token` → v3.
  - `github/codeql-action` (init + analyze) → latest v3 line.
  - `docker/setup-buildx-action` → v4.
  - `docker/login-action` → v4.
  - `docker/metadata-action` → v6.
  - `docker/build-push-action` → v7.
  - `dorny/test-reporter` → v3.
  - `fkirc/skip-duplicate-actions` → v5.3.2.
  - `sethvargo/ratchet` → v0.12.0.
- Verify `actions/github-script` and `thollander/actions-comment-pull-request`
are already at target and adjust only if needed.
- Install the ratchet CLI locally (note: it is not provisioned by
`scripts/setup-linters.sh`).
- Run `ratchet pin` against `.github/workflows/*.yml` and
`.github/actions/**/*.yml` to resolve the updated tags into 40-character commit
SHAs.
- Verify every `uses:` line now has a SHA whose trailing comment tag matches the
intended target version, and that the same logical action resolves to the same
SHA across all files.
- Re-pin the `sethvargo/ratchet` action reference used in the
`lint_github_actions` job of `ci.yml` to the new v0.12.0 SHA so CI validation
runs with the upgraded tool.

Phase 3: Verify breaking changes and validate workflows

Confirm that the major-version bumps do not break workflow behavior, with focused attention on the one high-risk consumer, then validate the full CI surface.

Task 1: Verify artifact upload/download behavior after major bumps

Guard against artifact-path regressions introduced by upload-artifact v5+/v6+/v7 and download-artifact v5+/v8.

• Confirm the coverage flow in ci.yml (single named artifact downloaded into coverage_artifact/, consumed by .github/actions/post-coverage-comment) still resolves the expected flat paths (coverage_artifact/cli/coverage/..., coverage_artifact/core/coverage/...).
• Confirm the OCR flow in ocr-review.yml (single named artifact ocr-review-output) still extracts flat after the v4 → v8 jump, since downstream steps cd ocr-review-output and read files directly.
• Primary regression target: verify the evals aggregation pipeline — _evals-run.yml uploads eval-logs-N, evals-nightly.yml's aggregate-results downloads all artifacts (no name, merge-multiple unset) into artifacts/, and scripts/aggregate-evals-cardinality.js requires each artifact in its own artifacts/eval-logs-N/ subdirectory (via extractAttemptFromPath / validateTopLevelArtifactDirs). Confirm the upgraded download-artifact still nests per-artifact subdirectories by default; if v8's default changes, set merge-multiple: false explicitly (or otherwise preserve the layout).
• Review dorny/test-reporter v2 → v3 and docker/* bumps for input/behavior changes affecting the test-report step in ci.yml/nightly.yml and the image build/push steps in build-sandbox.yml/release.yml; adjust inputs only if a breaking change is confirmed.

Task 2: Validate the full workflow suite

Confirm the acceptance criteria are met.

• Run the full CI suite (test, lint including the ratchet check, typecheck, format, build) and E2E, confirming no Node.js 20 deprecation warnings appear in any job log.
• Exercise/verify the nightly, smoke-test, and release workflows (the evals nightly aggregation being the key functional check) to confirm they still complete successfully with the new pins.

🤖 Prompt for AI agents

Implement Phase 3: verify that the major-version action bumps do not introduce
behavioral regressions, with special focus on artifact upload/download layout
dependencies, then validate the full CI/E2E/nightly/release surface.

Steps:
- Verify artifact-handling flows after the upload-artifact and download-artifact
major bumps:
- `ci.yml` coverage flow: confirm the single named artifact downloaded into
`coverage_artifact/` (consumed by `.github/actions/post-coverage-comment`) still
resolves flat paths like `coverage_artifact/cli/coverage/...` and
`coverage_artifact/core/coverage/...`.
- `ocr-review.yml` flow: confirm the single named artifact `ocr-review-output`
still extracts flat after the v4 → v8 download-artifact jump, since downstream
steps do `cd ocr-review-output` and read files directly.
- Primary regression target — the evals aggregation pipeline: `_evals-run.yml`
uploads artifacts named `eval-logs-N`; `evals-nightly.yml`'s `aggregate-results`
job downloads all artifacts (no `name` specified, `merge-multiple` unset) into
`artifacts/`; `scripts/aggregate-evals-cardinality.js` expects each artifact in
its own `artifacts/eval-logs-N/` subdirectory (relied on by
`extractAttemptFromPath` / `validateTopLevelArtifactDirs`). Confirm the upgraded
download-artifact version still nests per-artifact subdirectories by default; if
the default changed in v8, explicitly set `merge-multiple: false` (or otherwise
preserve the existing directory layout).
- Review `dorny/test-reporter` v2 → v3 and the `docker/*` action bumps for input
or behavior changes affecting the test-report step in `ci.yml`/`nightly.yml` and
the image build/push steps in `build-sandbox.yml`/`release.yml`; only adjust
inputs if a breaking change is confirmed.
- Validate the full workflow suite:
- Run the full CI suite (test, lint including the ratchet check, typecheck,
format, build) and E2E tests, confirming no Node.js 20 deprecation warnings
appear in any job log.
- Exercise/verify the nightly, smoke-test, and release workflows, with the evals
nightly aggregation being the key functional check, to confirm they all still
complete successfully with the new pins.

Research

The repository pins all GitHub Actions to immutable commit SHAs using the sethvargo/ratchet convention: uses: owner/repo@<40-char-SHA> # ratchet:owner/repo@vX.Y.Z. Ratchet runs only in CI (the lint_github_actions job in .github/workflows/ci.yml) and verifies that each pinned SHA still matches the semver tag recorded in its trailing comment. There is no local ratchet tooling. Sixteen workflow files under .github/workflows/ plus one composite action (.github/actions/post-coverage-comment/action.yml) reference third-party actions. Several files deviate from the standard comment format (bare # v4 comments, a comment-above-line style, or no comment), and the same logical action is pinned to divergent SHAs across files. The only functional regression risk from version bumps is the evals aggregation pipeline (_evals-run.yml → evals-nightly.yml → scripts/aggregate-evals-cardinality.js), which depends on the multi-artifact download layout.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: normalize all third-party GitHub Action pin comments to the
standard trailing `# ratchet:owner/repo@version` format and unify divergent
SHAs/tags for the same action across workflow files, establishing a clean
baseline for the ratchet CLI in Phase 2.

Steps:
- For every `uses:` line lacking a proper trailing ratchet comment, add one in
the standard `# ratchet:owner/repo@version` format:
- `.github/workflows/smoke-test.yml`: add `# ratchet:actions/checkout@<tag>`
(currently has no comment).
- `.github/workflows/release.yml`: convert bare `# v4` comment to ratchet
format.
- `.github/workflows/upstream-sync.yml`: convert bare `# v4.3.0` comment to
ratchet format.
- `.github/workflows/llxprt-scheduled-pr-triage.yml`: convert bare `# v4`
comments to ratchet format, including the commented-out
`actions/create-github-app-token` line.
- `.github/workflows/pr-review.yml` and
`.github/actions/post-coverage-comment/action.yml`: convert bare `# v3.0.1`
comments for `thollander/actions-comment-pull-request` to ratchet format.
- `.github/workflows/ci.yml` and `.github/workflows/e2e.yml`: convert the
comment-above-line style for `fkirc/skip-duplicate-actions` to the standard
trailing-comment style.
- Unify divergent SHAs/tags for the same logical action across files:
- `actions/checkout`: pick one target tag and replace all four divergent pins
(`08c6903c`/v5 and `08eba0b2`/v5 in `e2e.yml`; `11bd7190`/v4 in `release.yml`
and `llxprt-scheduled-pr-triage.yml`; `08eba0b1`/v4.3.0 in `upstream-sync.yml`)
so they reference the same tag.
- `actions/download-artifact`: pick one target tag and replace the v4 pin in
`.github/workflows/ocr-review.yml` so it matches the tag used in
`ci.yml`/`evals-nightly.yml`.
- In this phase, only make the `# ratchet:` tag values consistent — do not
resolve or change SHAs yet; SHA resolution happens via the ratchet CLI in Phase
2.
===============================================================================

Task: 2

Implement Phase 2: update ratchet comment tags to the chosen Node-24-native
target versions for every third-party action, then run the ratchet CLI to
resolve the immutable SHAs, which is the core change eliminating the Node 20
deprecation warnings.

Steps:
- Update the `# ratchet:` comment tag (not the SHA) for each action to its
target version:
  - `actions/upload-artifact`: v4 → latest published, targeting v7 per ticket.
  - `oven-sh/setup-bun`: re-pin to latest v2 release that ships Node 24.
  - `actions/checkout` → v7.
  - `actions/download-artifact` → v8.
  - `actions/setup-node` → v7.
  - `actions/cache` → v6.
  - `actions/setup-python` → v7.
  - `actions/create-github-app-token` → v3.
  - `github/codeql-action` (init + analyze) → latest v3 line.
  - `docker/setup-buildx-action` → v4.
  - `docker/login-action` → v4.
  - `docker/metadata-action` → v6.
  - `docker/build-push-action` → v7.
  - `dorny/test-reporter` → v3.
  - `fkirc/skip-duplicate-actions` → v5.3.2.
  - `sethvargo/ratchet` → v0.12.0.
- Verify `actions/github-script` and `thollander/actions-comment-pull-request`
are already at target and adjust only if needed.
- Install the ratchet CLI locally (note: it is not provisioned by
`scripts/setup-linters.sh`).
- Run `ratchet pin` against `.github/workflows/*.yml` and
`.github/actions/**/*.yml` to resolve the updated tags into 40-character commit
SHAs.
- Verify every `uses:` line now has a SHA whose trailing comment tag matches the
intended target version, and that the same logical action resolves to the same
SHA across all files.
- Re-pin the `sethvargo/ratchet` action reference used in the
`lint_github_actions` job of `ci.yml` to the new v0.12.0 SHA so CI validation
runs with the upgraded tool.
===============================================================================

Task: 3

Implement Phase 3: verify that the major-version action bumps do not introduce
behavioral regressions, with special focus on artifact upload/download layout
dependencies, then validate the full CI/E2E/nightly/release surface.

Steps:
- Verify artifact-handling flows after the upload-artifact and download-artifact
major bumps:
- `ci.yml` coverage flow: confirm the single named artifact downloaded into
`coverage_artifact/` (consumed by `.github/actions/post-coverage-comment`) still
resolves flat paths like `coverage_artifact/cli/coverage/...` and
`coverage_artifact/core/coverage/...`.
- `ocr-review.yml` flow: confirm the single named artifact `ocr-review-output`
still extracts flat after the v4 → v8 download-artifact jump, since downstream
steps do `cd ocr-review-output` and read files directly.
- Primary regression target — the evals aggregation pipeline: `_evals-run.yml`
uploads artifacts named `eval-logs-N`; `evals-nightly.yml`'s `aggregate-results`
job downloads all artifacts (no `name` specified, `merge-multiple` unset) into
`artifacts/`; `scripts/aggregate-evals-cardinality.js` expects each artifact in
its own `artifacts/eval-logs-N/` subdirectory (relied on by
`extractAttemptFromPath` / `validateTopLevelArtifactDirs`). Confirm the upgraded
download-artifact version still nests per-artifact subdirectories by default; if
the default changed in v8, explicitly set `merge-multiple: false` (or otherwise
preserve the existing directory layout).
- Review `dorny/test-reporter` v2 → v3 and the `docker/*` action bumps for input
or behavior changes affecting the test-report step in `ci.yml`/`nightly.yml` and
the image build/push steps in `build-sandbox.yml`/`release.yml`; only adjust
inputs if a breaking change is confirmed.
- Validate the full workflow suite:
- Run the full CI suite (test, lint including the ratchet check, typecheck,
format, build) and E2E tests, confirming no Node.js 20 deprecation warnings
appear in any job log.
- Exercise/verify the nightly, smoke-test, and release workflows, with the evals
nightly aggregation being the key functional check, to confirm they all still
complete successfully with the new pins.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!