ci: fix two release-pipeline bugs the first tag exposed

[oratis]

Summary

Two more latent bugs in release.yml, both surfaced by the second v0.3.0 run. Neither is a regression — v0.3.0 is the repo's first tag, so none of this had ever executed.

1. npm version cannot bump a package in a pnpm workspace

Set extension version from tag
  deepcode
  v0.3.0
  npm error code EUNSUPPORTEDPROTOCOL
  npm error Unsupported URL Type "workspace:": workspace:*

It writes the version, then dies reifying the lockfile against workspace:* dependencies.

build-vscode hit it. publish-cli has the identical step and would have hit it next — it had never run because it needs both build jobs to succeed first.

Both now edit the one key with node and verify the result. No resolver involved.

I confirmed the mechanism rather than assuming it: npm version succeeds on a bare copy of apps/vscode/package.json (no node_modules) and only fails after an install, which matches the CI log exactly. The replacement leaves workspace:* untouched.

2. The pinned Node sidecar checksum was wrong

shasum: WARNING: 1 computed checksum did NOT match
/Users/runner/work/_temp/node-v22.23.1-darwin-arm64.tar.xz: FAILED

The workflow pinned ef28d8fab2c0…. That matches no published tarball — not arm64, not x64.

The real hash, verified two independent ways:

Source	Value
nodejs.org/dist/v22.23.1/SHASUMS256.txt	fb526811…8a738d
Downloaded the 24.7 MB artifact and hashed it locally	fb526811…8a738d

So this integrity check had never passed once.

I corrected the pin rather than relaxing the check. A committed hash protects against a compromised nodejs.org in a way that fetching SHASUMS256.txt at build time does not — but only while the hash is right. Added the one-liner to re-derive it on the next Node bump.

Test plan

• Reproduced the npm version failure mode and verified the replacement preserves workspace:* while setting the version
• Verified the corrected checksum against Node's manifest and by hashing the real download
• Workflow job keys intact after the edit
• The real verification is the next tag run

Release notes label

• release-notes:internal — CI infrastructure

Still blocking the release, and not mine to decide

• deepcode-cli on npm is owned by someone else — guocong199708, guocong-bincai/deepcode-cli, currently 1.3.2, an unrelated Doubao CLI. apps/cli/package.json claims that exact name, so pnpm publish will 403. Renaming (scoped @deepcode/cli? something else?) is a branding decision that also rewrites the install line in README, quickstart, and the migration guide.
• No Actions secrets are configured (gh api …/actions/secrets returns none), so build-mac cannot sign or notarize and publish-cli has no NPM_TOKEN. docs/RELEASING.md §"One-time setup" lists the six.

Related

Follows #246. Blocks the v0.3.0 release (#245).

🤖 Generated with Claude Code