chore(deps): bump actions/download-artifact from 4.3.0 to 8.0.1

[dependabot]

Bumps actions/download-artifact from 4.3.0 to 8.0.1.

Release notes

Sourced from actions/download-artifact's releases.

v8.0.1

What's Changed

• Support for CJK characters in the artifact name by @​danwkennedy in actions/download-artifact#471
• Add a regression test for artifact name + content-type mismatches by @​danwkennedy in actions/download-artifact#472

Full Changelog: actions/download-artifact@v8...v8.0.1

v8.0.0

v8 - What's new

[!IMPORTANT] actions/download-artifact@v8 has been migrated to an ESM module. This should be transparent to the caller but forks might need to make significant changes.

[!IMPORTANT] Hash mismatches will now error by default. Users can override this behavior with a setting change (see below).

Direct downloads

To support direct uploads in actions/upload-artifact, the action will no longer attempt to unzip all downloaded files. Instead, the action checks the Content-Type header ahead of unzipping and skips non-zipped files. Callers wishing to download a zipped file as-is can also set the new skip-decompress parameter to true.

Enforced checks (breaking)

A previous release introduced digest checks on the download. If a download hash didn't match the expected hash from the server, the action would log a warning. Callers can now configure the behavior on mismatch with the digest-mismatch parameter. To be secure by default, we are now defaulting the behavior to error which will fail the workflow run.

ESM

To support new versions of the @actions/* packages, we've upgraded the package to ESM.

What's Changed

• Don't attempt to un-zip non-zipped downloads by @​danwkennedy in actions/download-artifact#460
• Add a setting to specify what to do on hash mismatch and default it to error by @​danwkennedy in actions/download-artifact#461

Full Changelog: actions/download-artifact@v7...v8.0.0

v7.0.0

v7 - What's new

[!IMPORTANT] actions/download-artifact@v7 now runs on Node.js 24 (runs.using: node24) and requires a minimum Actions Runner version of 2.327.1. If you are using self-hosted runners, ensure they are updated before upgrading.

Node.js 24

This release updates the runtime to Node.js 24. v6 had preliminary support for Node 24, however this action was by default still running on Node.js 20. Now this action by default will run on Node.js 24.

What's Changed

• Update GHES guidance to include reference to Node 20 version by @​patrikpolyak in actions/download-artifact#440
• Download Artifact Node24 support by @​salmanmkc in actions/download-artifact#415
• fix: update @​actions/artifact to fix Node.js 24 punycode deprecation by @​salmanmkc in actions/download-artifact#451
• prepare release v7.0.0 for Node.js 24 support by @​salmanmkc in actions/download-artifact#452

... (truncated)

Commits

• 3e5f45b Add regression tests for CJK characters (#471)
• e6d03f6 Add a regression test for artifact name + content-type mismatches (#472)
• 70fc10c Merge pull request #461 from actions/danwkennedy/digest-mismatch-behavior
• f258da9 Add change docs
• ccc058e Fix linting issues
• bd7976b Add a setting to specify what to do on hash mismatch and default it to error
• ac21fcf Merge pull request #460 from actions/danwkennedy/download-no-unzip
• 15999bf Add note about package bumps
• 974686e Bump the version to v8 and add release notes
• fbe48b1 Update test names to make it clearer what they do
• Additional commits viewable in compare view

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 27, 2026, 8:15 PM ET / July 28, 2026, 00:15 UTC.

ClawSweeper review

What this changes

This PR changes three actions/download-artifact steps in the tag-driven release workflow from pinned v4.3.0 to pinned v8.0.1.

Merge readiness

⛔ Blocked until real behavior proof is added - 3 items remain

Keep this PR open for maintainer review: it is a narrow, SHA-pinned release-workflow dependency update, but v8 changes artifact-download failure behavior and the supplied evidence does not show a tag-release run exercising the three changed downloads. Likely related people: the current release-workflow history is not attributable from the supplied review context, so routing confidence is low.

Priority: P2
Reviewed head: 52447810d2c215559400cd1f9a86693057e2b9eb
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The focused, SHA-pinned patch is plausible, but it lacks real release-path proof for a major action version with changed failure semantics.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body contains upstream release notes and the supplied CI results are supplemental; no after-fix, release-path output demonstrates the three changed v8 downloads in a real tag-like workflow. Attach redacted rehearsal output or logs—excluding private endpoints, tokens, and other sensitive details—then update the PR body for a fresh review.
Patch quality	🦐 gold shrimp (3/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The PR body contains upstream release notes and the supplied CI results are supplemental; no after-fix, release-path output demonstrates the three changed v8 downloads in a real tag-like workflow. Attach redacted rehearsal output or logs—excluding private endpoints, tokens, and other sensitive details—then update the PR body for a fresh review.
Evidence reviewed	4 items	Scoped workflow diff: The branch changes only .github/workflows/release.yml, replacing three fully pinned actions/download-artifact v4 references with the fully pinned v8.0.1 commit. Release-path impact: The changed steps download all bindings and the release package before package assembly and platform smoke checks, so an artifact digest or download behavior change can affect tag-driven release completion. Upstream major-version behavior: The PR body documents that v8 makes artifact digest mismatches fail by default and that v7 runs on Node.js 24; this is a release-automation behavior change rather than a cosmetic pin refresh.
Findings	None	None.
Security	None	None.

How this fits together

The release workflow builds platform bindings and package artifacts, then downloads those artifacts in later jobs to assemble and smoke-test the publishable package. These download steps sit on the release-critical path between artifact creation and package validation.

flowchart LR
  A[Release tag] --> B[Build bindings]
  B --> C[Upload release artifacts]
  C --> D[Download artifacts]
  D --> E[Assemble release package]
  E --> F[Platform smoke checks]
  F --> G[Publish release]

Loading

Decision needed

Question	Recommendation
Should the release pipeline adopt v8’s stricter digest-mismatch failure behavior after a release-path rehearsal confirms the repository’s artifacts and runners are compatible?	Validate then merge: Run or inspect a non-publishing release rehearsal that exercises the changed downloads, then merge if it completes with the expected artifacts.

Why: The code change is mechanically small, but v8 intentionally changes failure semantics on the tag-driven release path; accepting that operational behavior requires repository-owner judgment.

Before merge

• Resolve merge risk (P1) - actions/download-artifact v8 changes digest mismatches from warnings to hard failures, so an integrity mismatch that previously allowed a tag release to continue will now stop that release.
• Resolve merge risk (P1) - The supplied checks do not demonstrate the tag-driven release workflow executing the three updated artifact-download steps end to end.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release action references	3 changed, 0 added, 0 removed	All changes target artifact downloads on the tag-driven release path, concentrating the operational impact in one critical workflow.
Workflow surface	1 workflow changed	The patch does not alter package code or dependency lockfiles; review should focus on release-run compatibility.

Merge-risk options

Maintainer options:

1. Exercise the release artifact path (recommended)
   Before merge, obtain redacted output from a non-publishing release rehearsal that downloads the bindings and release package with v8.
2. Accept the release behavior change
   Merge with explicit owner acceptance that digest mismatches will now fail a tag release, after the remaining checks complete.

Technical review

Best possible solution:

Keep the SHA pinning, complete the remaining checks, and attach redacted evidence from a non-publishing release rehearsal or equivalent run showing all three v8 artifact downloads complete successfully.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a release-workflow dependency upgrade, not a report of broken end-user behavior. The relevant verification is a real release-path execution of the modified download steps.

Is this the best way to solve the issue?

Unclear: retaining full commit-SHA pins and updating all three matching calls is the narrow implementation, but a release rehearsal is needed to establish that v8’s changed digest and runtime behavior is safe here.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 1db7c7fa4a1c.

Labels

Label changes:

• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body contains upstream release notes and the supplied CI results are supplemental; no after-fix, release-path output demonstrates the three changed v8 downloads in a real tag-like workflow. Attach redacted rehearsal output or logs—excluding private endpoints, tokens, and other sensitive details—then update the PR body for a fresh review.
• remove status: 👀 ready for maintainer look: Current PR status label is status: 📣 needs proof.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.

Label justifications:

• P2: This is a bounded but release-critical workflow dependency upgrade whose compatibility needs confirmation before landing.
• merge-risk: 🚨 automation: The PR changes artifact-download behavior in the release workflow, including v8’s stricter digest-mismatch failure mode.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body contains upstream release notes and the supplied CI results are supplemental; no after-fix, release-path output demonstrates the three changed v8 downloads in a real tag-like workflow. Attach redacted rehearsal output or logs—excluding private endpoints, tokens, and other sensitive details—then update the PR body for a fresh review.

Evidence

What I checked:

• Scoped workflow diff: The branch changes only .github/workflows/release.yml, replacing three fully pinned actions/download-artifact v4 references with the fully pinned v8.0.1 commit. (.github/workflows/release.yml:211, 52447810d2c2)
• Release-path impact: The changed steps download all bindings and the release package before package assembly and platform smoke checks, so an artifact digest or download behavior change can affect tag-driven release completion. (.github/workflows/release.yml:211, 1db7c7fa4a1c)
• Upstream major-version behavior: The PR body documents that v8 makes artifact digest mismatches fail by default and that v7 runs on Node.js 24; this is a release-automation behavior change rather than a cosmetic pin refresh. (.github/workflows/release.yml:211, 52447810d2c2)
• Current validation state: The supplied checks show workflow linting and many platform checks succeeding, but the release-specific Windows native check and Cargo audit were still in progress and no completed tag-release artifact-download proof is attached. (.github/workflows/release.yml:251, 52447810d2c2)

Likely related people:

• unknown: The available review context identifies the affected release workflow but does not provide usable current-main blame or log attribution for its original or recent human owners. (role: release-workflow history owner; confidence: low; files: .github/workflows/release.yml)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Attach redacted output from a non-publishing release rehearsal that exercises the three updated downloads.
• Wait for the remaining Windows native and Cargo audit checks to complete successfully.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (1 earlier review cycle)

• reviewed 2026-07-27T17:32:04.613Z sha 535bec0 :: needs maintainer review before merge. :: none

[steipete]

Merged after exact-head dependency verification.

Tested at exact head 52447810d2c215559400cd1f9a86693057e2b9eb:

• GitHub CI: full Node 22/24, native, package-smoke, coverage, benchmark, workflow-lint, CodeQL, clippy, and audit checks green
• Codex autoreview: clean, verified the pinned SHA is the official v8.0.1 release and the existing name, pattern, and path inputs remain compatible

Landed as 502a2652d87f9d44b274022abc917b7692e03548. Caveat: the updated download action is used by the protected tag release workflow, so its artifact transfer path will next run on an actual release tag; actionlint and the repository matrix are green.