ci: define and automate beta releases

[joseph-shih-wandb]

Summary

• define the beta release policy and implement it with Changesets and GitHub Actions
• open/update a version and changelog PR when releasable changesets reach main
• publish only @coreweave/cwsandbox from an approved release-PR merge
• keep release:version as the pre-approval command and consolidate post-approval work into release:publish
• use npm trusted publishing/OIDC, the beta dist-tag, v<version> tags, and GitHub Releases

Release flow

1. A user-visible SDK change includes a changeset.
2. The workflow opens or updates chore: release packages from changeset-release/main with the proposed beta version and changelog.
3. A maintainer reviews and merges that PR; this is the single human approval gate.
4. The publish job enters the release GitHub Environment and runs pnpm check.
5. The single post-approval pnpm release:publish command verifies through GitHub that its commit came from the merged release PR, rejects an existing npm version, packs and publishes the core tarball with --tag beta, and writes the GitHub Release notes.
6. After npm succeeds, the workflow creates the matching Git tag and GitHub Release.

Safety boundaries

• the publish job uses the release environment so GitHub and npm can enforce a branch-bound OIDC identity
• publish eligibility requires an associated merged PR with base main, head changeset-release/main, and title chore: release packages
• workflow version/publish jobs also require main, including manual dispatches
• core is hard-coded as the only publish directory; both adapters are ignored until readiness review
• a release-time allowlist check fails if another workspace package is not explicitly excluded
• latest is never passed to npm, and existing npm versions are rejected before publish
• no long-lived npm token is stored

Merging this PR will not republish the current 0.5.0-beta.0: that version already exists and this PR contains no release changeset, so release selection should be none.

One-time setup before the first new release

• enable Allow GitHub Actions to create and approve pull requests in repository Actions settings
• create a GitHub Environment named release, select Selected branches and tags, and allow only branch main; no required reviewers are needed
• configure npm trusted publishing for package @coreweave/cwsandbox, repository coreweave/cwsandbox-js, workflow filename release.yml, environment release, and allowed action npm publish

Testing

• pnpm check — 21/21 tasks passed after merging current main, including the 0.5.0-beta.0 source and Vitest 5 toolchain
• release provenance tests accept the merged Changesets release PR and reject open, wrong-title, wrong-base, and wrong-head PRs
• release orchestration tests verify check → publish → notes ordering, dry-run forwarding, and that failed approval checks prevent publishing
• the package suite passes 11/11 tests, including release orchestration and package-consumer checks

[matthoare117-wandb]

why not just 1 release?

[joseph-shih-wandb]

Great question! I'm trying to avoid combining the execution across the human approval step:

Current flow:
version -> release PR -> human merge -> check -> pack/publish -> notes -> GitHub Release

I can:

• keep release:version separate because it creates the approval PR (write access to versions/changelog, human approves by merging)
• combine the three post-merge operations into one release:publish command