[raviships]

Summary

This replaces Dependabot PR #314 (closed), which only bumped the pin. changesets/action v2 renamed the inputs and outputs that release.yml uses. It also refuses to start when @changesets/cli 2.x is installed (validateChangesetsCliVersion in src/utils.ts), so this PR upgrades the CLI as well. Without that, every release run would fail at startup.

Commit 1: chore: upgrade Changesets CLI to v3

• @changesets/cli 2.31.1 → 3.0.3, @changesets/changelog-github 0.7.0 → 1.0.1.
• .changeset/config.json $schema → @changesets/config@4.0.1. The old config@3.2.0 URL returns a 404.

Commit 2: ci: migrate release workflow to changesets/action v2, in the release and maintenance jobs:

-uses: changesets/action@a45c4d59… # v1.9.0
+uses: changesets/action@ae32849d… # v2.1.2
 with:
-  version: pnpm -s run version
-  publish: pnpm run release
-env:
-  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-  NPM_TOKEN: ''
+  version-script: pnpm -s run version
+  publish-script: pnpm run release

• Report step. "Report published packages" reads published-packages (v1: publishedPackages) through env: instead of inlining ${{ }} in the script.
• GITHUB_TOKEN env removed. v2 reads only the github-token input, which defaults to github.token, the same token as before. The action passes it as GITHUB_TOKEN to the version and publish scripts, so changelog-github still gets a token.
• NPM_TOKEN: '' removed. v2 dropped its .npmrc writing (Remove npm auth handling in favor of docs changesets/action#695), and nothing in v2.1.2 or CLI 3.0.3 reads NPM_TOKEN. npm auth still uses OIDC: CLI v2 and v3 both publish with pnpm publish.

What changes in practice

Area	v1	v2 / CLI v3
Version Packages commit	Committed and force-pushed with the git CLI as github-actions[bot], unsigned	Created through the GitHub GraphQL API (@changesets/ghcommit), so it is signed by GitHub and shows Verified. Author is still github-actions[bot]. Still force-updates changeset-release/<branch>.
Release tags	Annotated tags made by changeset publish, pushed with git	Lightweight refs created through the REST API, on the same commit (the one that triggered the run) with the same @edgestore/<pkg>@<version> names. A tag that fails to create now logs a warning instead of failing the run.
GitHub Releases	Created (default)	Still created (create-github-releases defaults to true, which forces push-git-tags)
Detecting what was published	Parsed from stdout	Read from the CHANGESETS_OUTPUT file. pnpm run release → changeset publish inherits that env var.
Git identity	Set by the setup-git-user input	Uses github-actions[bot] only when no identity is configured, which is the case here
Workflow triggers	Version PR pushes made with GITHUB_TOKEN trigger no workflows	Unchanged
Changelogs	—	A fixed-group package with no entries gets "No changes in this release." (e.g. sdk, shared). Lists are formatted tight.
Prerelease state	Consumed changesets are listed in pre.json	Consumed changesets move to .changeset/pre/. pre.json keeps mode and tag, so the jq checks in release.yml, start-rc.yml and promote-next.yml still work. next is dormant, so nothing needs migrating.
changeset version with no changesets	Exits 0	Exits 1, except after pre exit. The canary job requires a changeset anyway (RELEASING.md), so a canary run without one now fails loudly.

Other workflows. promote-next.yml, start-rc.yml, ci.yml and storage.yml don't use the action. promote-next (pre exit + pnpm -s run version) and the canary job call the CLI directly, so they keep their GITHUB_TOKEN env, which changelog-github needs.

Job split (not done). The v2 README recommends sub-actions to keep id-token: write away from install and build. That would mean three jobs per lane: /select-mode → /version, or /pack (build, no OIDC) → /publish (OIDC + contents: write for tags and releases), with artifacts passed between them. Both the release and maintenance lanes would need it, and the maintenance dist-tag checks would move into the publish job. The npm trusted publisher keys on release.yml and would stay valid. It's a reasonable follow-up, but it isn't a simple change, so I kept the current structure.

Evidence

• Pin. Tag v2.1.2 → annotated tag object 66d7d1dd → commit ae32849d5ba541f9ae29e40e22a623bc13562f51. That commit is the head of the action's v2 release branch and is the same SHA Dependabot proposed in chore(deps): bump changesets/action from 1.9.0 to 2.1.2 #314. All inputs, outputs and behavior described above were checked against the v2.1.2 source (action.yml, src/index.ts, src/run.ts, src/github.ts, src/utils.ts).
• actionlint 1.7.12 (release binary, SHA-256 checked) reports no errors on .github/workflows/*.yml. shellcheck isn't installed, so the shell bodies were not linted. All workflows parse as strict YAML.
• pnpm -s run version ran in scratch clones of origin/main with real git history, once with CLI 2.31.1 and once with 3.0.3. Both exit 0 and touch the same 29 files as the open Version Packages PR Version Packages #310. The only content differences are changelog formatting:

   ## 1.0.1
  +
  +No changes in this release.

• Canary. changeset version --snapshot canary + sync-versions on v3 gives 0.0.0-canary-20261024025740, the same shape as before.
• Prerelease lane on v3. pre enter next → run version gives 1.0.1-next.0, and pre.json is {mode, tag}. The release.yml next check and the start-rc jq transform both pass. pre exit + run version gives 1.0.1 and removes pre.json.
• Report step. A smoke test with a sample PUBLISHED_PACKAGES value renders the bullet list. pnpm check:dependencies passes.

Can't be verified before merge. release.yml runs only on pushes to main/next and on workflow_dispatch, so none of the action's GitHub-side behavior runs in PR CI.

• The first push to main after merge runs the version path. Two changesets are pending, so it regenerates PR Version Packages #310 with CLI v3 and commits through the API.
• Publishing (OIDC, tags through the API, GitHub Releases, the published-packages summary) is exercised only when Version Packages #310 is merged.
• The maintenance and next lanes are exercised only when someone uses them.

Risk and rollback

Door: Two-way. Reverting restores action v1 and CLI 2. The next run would then force-update changeset-release/main again with the v1 output. Lightweight tags and Releases created in the meantime remain, and they are valid.

Blast radius: Publishing of @edgestore/* to npm, plus Version Packages PRs, tags and Releases. No package source changes, so no Changeset is needed. The lockfile diff is the Changesets dependency tree, plus pnpm re-resolving the astro example's @emnapi/runtime peer from 1.11.2 to 1.11.3. Both versions were already in the lockfile.

Watch on the first runs:

1. After merge, the release run on main should update PR Version Packages #310 with a Verified "Version Packages" commit and add "No changes in this release." under sdk and shared.
2. When Version Packages #310 is merged:
   • the npm publish should succeed over OIDC;
   • @edgestore/*@1.0.1 tags and Releases should appear;
   • the step summary should list the packages.
3. A Failed to read changesets output or Failed to create git tag warning means published may be false, which skips the summary and the maintenance dist-tag checks.

By: Claude Opus 5.5 High on Claude Code

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
edgestore-docs	Ready	Preview	Oct 24, 2026 3:00am UTC
example-access-control	Ready	Preview	Oct 24, 2026 3:00am UTC
example-components	Ready	Preview	Oct 24, 2026 3:00am UTC

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-24T03:01:21.035680Z	cd45e38	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.