chore(deps): bump actions/upload-artifact from 4.6.2 to 7.0.1

[dependabot]

Bumps actions/upload-artifact from 4.6.2 to 7.0.1.

Release notes

Sourced from actions/upload-artifact's releases.

v7.0.1

What's Changed

• Update the readme with direct upload details by @​danwkennedy in actions/upload-artifact#795
• Readme: bump all the example versions to v7 by @​danwkennedy in actions/upload-artifact#796
• Include changes in typespec/ts-http-runtime 0.3.5 by @​yacaovsnc in actions/upload-artifact#797

Full Changelog: actions/upload-artifact@v7...v7.0.1

v7.0.0

v7 What's new

Direct Uploads

Adds support for uploading single files directly (unzipped). Callers can set the new archive parameter to false to skip zipping the file during upload. Right now, we only support single files. The action will fail if the glob passed resolves to multiple files. The name parameter is also ignored with this setting. Instead, the name of the artifact will be the name of the uploaded file.

ESM

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

What's Changed

• Add proxy integration test by @​Link- in actions/upload-artifact#754
• Upgrade the module to ESM and bump dependencies by @​danwkennedy in actions/upload-artifact#762
• Support direct file uploads by @​danwkennedy in actions/upload-artifact#764

New Contributors

• @​Link- made their first contribution in actions/upload-artifact#754

Full Changelog: actions/upload-artifact@v6...v7.0.0

v6.0.0

v6 - What's new

[!IMPORTANT] actions/upload-artifact@v6 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. v5 had preliminary support for Node.js 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

• Upload Artifact Node 24 support by @​salmanmkc in actions/upload-artifact#719
• fix: update @​actions/artifact for Node.js 24 punycode deprecation by @​salmanmkc in actions/upload-artifact#744
• prepare release v6.0.0 for Node.js 24 support by @​salmanmkc in actions/upload-artifact#745

Full Changelog: actions/upload-artifact@v5.0.0...v6.0.0

v5.0.0

What's Changed

... (truncated)

Commits

• 043fb46 Merge pull request #797 from actions/yacaovsnc/update-dependency
• 634250c Include changes in typespec/ts-http-runtime 0.3.5
• e454baa Readme: bump all the example versions to v7 (#796)
• 74fad66 Update the readme with direct upload details (#795)
• bbbca2d Support direct file uploads (#764)
• 589182c Upgrade the module to ESM and bump dependencies (#762)
• 47309c9 Merge pull request #754 from actions/Link-/add-proxy-integration-tests
• 02a8460 Add proxy integration test
• b7c566a Merge pull request #745 from actions/upload-artifact-v6-release
• e516bc8 docs: correct description of Node.js 24 support in README
• 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

The PR updates both artifact-upload steps in the release workflow from actions/upload-artifact v4 to the immutable v7.0.1 commit.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

The two-line, immutable-SHA update is mechanically sound and aligns with GitHub’s Node 24 action transition, but the release workflow itself is not exercised by the supplied PR checks. Keep this PR open for a maintainer to confirm that any self-hosted release runners meet the Node 24-era runner requirement before merging.

Priority: P3
Reviewed head: bec7ac546a2d5d60a2c65e04c102ce1e113f1dac
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, consistently pinned workflow update with strong CI signal; release-runner compatibility remains the only material merge check.
Proof confidence	🌊 off-meta tidepool	Not applicable: This Dependabot CI-maintenance PR is exempt from the external-contributor real-behavior-proof gate; the supplied platform and workflow checks are supplemental validation only.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This Dependabot CI-maintenance PR is exempt from the external-contributor real-behavior-proof gate; the supplied platform and workflow checks are supplemental validation only.
Evidence reviewed	4 items	Scoped immutable action update: The proposed diff changes exactly two uses: entries in the release workflow, retaining full 40-character commit pinning while moving from the v4 commit to the v7.0.1 commit. Second release artifact path updated consistently: The release-package upload uses the same v7.0.1 immutable commit, so the binding and package artifact paths do not diverge in action version. Runner compatibility remains the material merge question: The prior completed review correctly identified that the v6-and-later action runtime requires Node 24-capable runners; supplied checks validate ordinary CI but do not demonstrate an end-to-end release upload on the release runner fleet.
Findings	None	None.
Security	None	None.

How this fits together

The release workflow builds native bindings and release packages, then uploads them as GitHub Actions artifacts for subsequent release processing. This update changes the JavaScript action runtime used at those two artifact handoff points.

flowchart LR
  A[Release trigger] --> B[Build native bindings]
  B --> C[Upload binding artifacts]
  A --> D[Assemble release packages]
  D --> E[Upload release artifacts]
  C --> F[Release workflow outputs]
  E --> F

Loading

Decision needed

Question	Recommendation
Do all runners that can execute the release workflow support the Node 24 action runtime required by actions/upload-artifact v7?	Confirm runner support and merge: Verify that release jobs are GitHub-hosted or every eligible self-hosted runner meets the Node 24-era runner requirement, then merge this pinned dependency update.

Why: Repository source and supplied CI results establish the narrow workflow change, but runner-fleet version and hosting are operational facts not provable from the PR diff alone.

Before merge

• Resolve merge risk (P1) - If any release job runs on an outdated self-hosted runner, the Node 24 action runtime can make artifact upload fail after builds complete, blocking a release despite ordinary CI passing.
• Complete next step (P2) - A maintainer must confirm release-runner compatibility; no narrow repository-only repair is justified from the supplied evidence.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Workflow surface	1 workflow changed	Only the release automation path is affected; package source and runtime behavior are untouched.
Action references	2 changed, 0 added, 0 removed	Both artifact handoff points move together to the same immutable upstream commit.

Merge-risk options

Maintainer options:

1. Verify release-runner compatibility (recommended)
   Confirm the actual release runner fleet supports the Node 24 action runtime, then merge the existing two-line immutable-SHA update.
2. Defer until runner upgrade
   Keep the v4 pin temporarily if a release-capable self-hosted runner cannot be upgraded before the action transition.

Technical review

Best possible solution:

Confirm that every self-hosted runner eligible for the release workflow supports the Node 24 action runtime (or that release jobs are GitHub-hosted), then merge the existing immutable-SHA update without changing artifact inputs or defaults.

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

Not applicable: this PR updates release automation rather than correcting a user-reported product failure. The relevant validation is a release-runner compatibility check, not a product reproduction path.

Is this the best way to solve the issue?

Yes, conditionally: updating the immutable action pin is the narrowest maintainable response to the Node 24 transition, provided the release runner fleet is confirmed compatible before merge.

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P3: This is a narrow dependency-maintenance change whose primary risk is release-automation compatibility rather than current package behavior.
• merge-risk: 🚨 compatibility: The major action upgrade changes its JavaScript runtime requirement and can be incompatible with outdated self-hosted release runners.
• merge-risk: 🚨 automation: A runner mismatch would cause artifact upload to fail in the release workflow even though general CI checks succeed.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This Dependabot CI-maintenance PR is exempt from the external-contributor real-behavior-proof gate; the supplied platform and workflow checks are supplemental validation only.

Evidence

What I checked:

• Scoped immutable action update: The proposed diff changes exactly two uses: entries in the release workflow, retaining full 40-character commit pinning while moving from the v4 commit to the v7.0.1 commit. (.github/workflows/release.yml:171, bec7ac546a2d)
• Second release artifact path updated consistently: The release-package upload uses the same v7.0.1 immutable commit, so the binding and package artifact paths do not diverge in action version. (.github/workflows/release.yml:221, bec7ac546a2d)
• Runner compatibility remains the material merge question: The prior completed review correctly identified that the v6-and-later action runtime requires Node 24-capable runners; supplied checks validate ordinary CI but do not demonstrate an end-to-end release upload on the release runner fleet. (bec7ac546a2d)
• Checks provide supplemental confidence: The supplied check list shows workflow linting, CodeQL, package smoke tests, and platform checks succeeding on this head; Cargo clippy and audit was still in progress at review time. (bec7ac546a2d)

Likely related people:

• unknown: The available review context identifies the release workflow but does not provide reliable local git-history attribution for its current maintainers. (role: release workflow owner; confidence: low; files: .github/workflows/release.yml)

Rank-up moves

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

• Confirm the release workflow’s runner fleet is Node 24-capable before merging.

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:34:56.149Z sha e3e6820 :: needs maintainer review before merge. :: none

[steipete]

Merged after exact-head dependency verification.

Tested at exact head bec7ac546a2d5d60a2c65e04c102ce1e113f1dac:

• 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 v7.0.1 release and both upload configurations remain compatible

Landed as 3ae1896bcd7f7aca5d50f704ff0b64f8d79b0ca3. Caveat: the two updated uploads in the protected tag release workflow will next execute on an actual release tag; actionlint and the repository matrix are green.