Validate that projects use Changesets CLI v3 and direct Changesets CLI v2 users to changesets/action@v1 - #699
Merged
Merged
Conversation
…I v2 users to `changesets/action@v1`
🦋 Changeset detectedLatest commit: 09fa258 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
beeequeue
reviewed
Jul 22, 2026
bluwy
reviewed
Jul 23, 2026
bluwy
approved these changes
Jul 23, 2026
Merged
Merged
This was referenced Aug 12, 2026
This was referenced Aug 17, 2026
This was referenced Aug 21, 2026
xinaesthete
added a commit
to Taylor-CCB-Group/SpatialData.js
that referenced
this pull request
Aug 26, 2026
…iring (#168) #156 bumped changesets/action from v1 to v2 inside the routine weekly `actions` Dependabot group. It was green — release.yml is triggered only by `push: main`, so no pull request can exercise it — and broke the release on main, which #167 reverted by pinning the action back to v1. The action and the CLI are a matched pair, so take both majors together: - `@changesets/cli` -> ^3.0.1 and `@changesets/changelog-github` -> ^1.0.0. changesets/action v2 dropped Changesets v2 support and hard-errors on it (changesets/action#699). Config `$schema` moved to @changesets/config@4.0.0. - release.yml migrates to the v2 input names (`version` -> `version-script`, `title` -> `pr-title`, `commit` -> `commit-message`) and drops the `GITHUB_TOKEN` env block; `github-token` already defaults to the workflow token, and v2's `runVersion` still injects GITHUB_TOKEN into the version script so changelog-github keeps resolving PR and author links. Both halves of the breakage are now checked at pull-request time: - scripts/check-release-toolchain.mjs asserts the action major and the CLI major agree, and that every `with:` key is a real input of that major. Unknown inputs are silently dropped by GitHub Actions rather than failing, so a mis-migrated step would have run `changeset version` under a default PR title instead of `pnpm version-packages`. It runs as a `release-toolchain` job in Workflow Lint, which needs no dependency install, and as `pnpm lint:release-toolchain` locally. - The Dependabot `actions` group is restricted to minor/patch, so action majors arrive as individually reviewable PRs. Same rationale already documented for the npm groups, plus the ecosystem-specific one: an action major is the bump this CI is structurally unable to test. Verified by running `pnpm version-packages` against the v3 CLI (correct bumps and linked changelog entries, reverted afterwards), `pnpm install --frozen-lockfile`, actionlint 1.7.12, and all four failure modes of the new check. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
6 of 7 tasks
arshad-shah
added a commit
to arshad-shah/extforge
that referenced
this pull request
Sep 1, 2026
The 1.0.0 and 1.1.0 releases published to npm but created no git tag and no GitHub release, while the workflow reported success. changesets/action v1 detects what was published by regex-matching `changeset publish` stdout for `New tag: <pkg>@<version>`. #77 upgraded @changesets/cli to v3, whose clack-style output no longer prints that line, so the action concluded nothing had been published and skipped both the tag push and the release creation without failing. Tags were created on the runner and discarded with it — which is why `git ls-remote --tags` still stops at 0.6.0. Upstream replaced stdout parsing with a CHANGESETS_OUTPUT file in v2 (changesets/action#678) and v2 now rejects the CLI v2/action v1 mismatch outright (changesets/action#699). v2 renamed every input, so this is not a bare SHA bump: version -> version-script, publish -> publish-script, commit -> commit-message, title -> pr-title. Both env vars are dropped. GITHUB_TOKEN is no longer read from the environment (changesets/action#674); the `github-token` input defaults to `github.token`, which is what was being passed. NPM_TOKEN is no longer used to write an .npmrc (changesets/action#695) — publishing already goes through OIDC trusted publishing, confirmed by the SLSA provenance attestation on the published 1.1.0 tarball. v2 pushes commits and tags through the GitHub API rather than the git CLI, so `persist-credentials: false` stays safe and tags are signed with GitHub's GPG key. Claude-Session: https://claude.ai/code/session_01AZSFjNFjuoeXUjuFkA6Cha Co-authored-by: Arshad shah <arshad.shah@hmhco.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 4, 2026
shinyaoguri
added a commit
to shinyaoguri/cosense-site-kit
that referenced
this pull request
Sep 4, 2026
## 目的 dependabot が出していた 2 件は**片方だけマージするとリリースが壊れる**組み合わせだったので、1 PR にまとめて移行する。 - #148 `changesets/action` v1.9.0 → v2.1.1 - #150 `@changesets/cli` 2.31.1 → 3.0.0 理由: 1. **相互依存**。action v2 はプロジェクトが Changesets CLI v3 であることを検証し、v2 なら `changesets/action@v1` を使えと言って落ちる（action v2.0.0 / changesets/action#699）。逆に CLI v3 だけ上げても action v1 は v2 系パッケージ前提。 2. **入力名が全面改名 + `GITHUB_TOKEN` env 廃止**（changesets/action#681・#674）。`version`→`version-script`、`publish`→`publish-script`、`commit`→`commit-message`、`title`→`pr-title`。GitHub Actions は**未知入力を警告のみで無視する**ので、SHA だけの bump はリリースを黙って無効化する。 3. **CI では検知できない**。`ci.yml` は `release.yml` を実行しないため、#148 単独でも `check` は green。#136 で整理した「dependabot はマニフェストしか書き換えず、手で追随すべき箇所は黙ってドリフトする」パターンそのもの。 ## 変更点 - **`.github/workflows/release.yml`**: pin を v2.1.1 の SHA へ、入力を v2 名へ移行し、`github-token` を明示（v2 は env を見ない）。`commit-message` / `pr-title` は v2 の既定値 `Version Packages` ではなく Conventional Commits を保つため明示継続（squash merge のコミット要約になる）。npm 認証は従来どおり OIDC trusted publishing でトークンは持たない。 - **`package.json`**: `@changesets/cli` を `^3.0.0`、`engines.node` を `>=22.11`（CLI v3 の engines は `^22.11 || ^24 || >=26`）。 - **`.changeset/config.json`**: `$schema` を `@changesets/config@4.0.0` へ（CLI v3 が引くのは config v4）。削除された `prettier` は未使用、`privatePackages` の既定変更で影響を受ける private パッケージ（`site/`）に changeset は無いので他の移行は不要。 - **`test/dependency-consistency.test.ts`**: 再発防止のガードを 2 本追加。 - action の pin（`# vX.Y.Z` コメント）の major と `@changesets/cli` の major が対応表（1↔2, 2↔3）どおりであること。表に無い major が pin されたら落として手で判断させる。 - pin した major の入力名だけが使われていること（v1 名の残留と `GITHUB_TOKEN:` env 依存を落とす）。 - `.changeset/config.json` の `$schema` の major が `package-lock.json` の解決済み `@changesets/config` と一致すること。**major のみ**の比較にしたのは、こちらが transitive で minor が `npm install` のたびに動きうるため（#145 の「無関係な PR が赤くなる」の回避）。 - **ADR 0004**: action と CLI の major を同時にしか動かせない制約と、その整合をテストで担保していることを追記。 changeset は無し（`packages/*` を触らないので公開物に変化なし）。 ## 確認方法 - `npm run build` / `npm test`（36 files・367 tests green）/ `npm run typecheck`（0 errors） - 新ガードが**赤くなるのを見てから**仕上げた: 入力名を v1 に戻す・CLI を `^2` に戻す・`$schema` を `3.0.0` に戻す・pin のバージョンコメントを外す、の 4 ケースで期待どおり該当テストだけが落ちる - **CLI v3 の疎通**: 捨て changeset で `npx changeset status`（`@cosense-site-kit/core -> 0.4.4` を提示）→ `npx changeset version`（bump + CHANGELOG + changeset 消費）まで確認し、変更は戻した。依存パッケージまで連鎖しない挙動は v2 のときと同じ（cf. b80edbc） - pin した SHA `8488615a…` が v2.1.1 タグの実体と一致することと、入力名がその SHA の `action.yml` と一致することを確認 - **マージ後**: main の `Release` 実行ログで action v2 が CLI v3 検証を通り、未知入力の警告が出ていないことを確認する（changeset ゼロなので publish モードで no-op が正しい）。壊れていても `release.yml` の 1 ステップの revert で v1 系に戻せる ## 補足 `npm run lint` はこの worktree（`.claude/worktrees/*` 配下）からは 0 files で落ちる。`biome.json` の `!**/.claude` が biome へ渡す `.`（= 絶対パス）にマッチするためで、この PR とは無関係な既存の papercut（別途 Issue にする）。CI は `.claude` を含まないパスで走るので影響なし。変更ファイルは明示パスで biome を通して green を確認済み。 --- <sub>🤖 Assisted by [Claude Code](https://claude.com/claude-code)</sub>
ByronDWall
pushed a commit
to commercetools/nimbus
that referenced
this pull request
Sep 23, 2026
…1995) * ci(release): upgrade changesets/action to v2 for @changesets/cli v3 @changesets/cli v3 no longer prints the "New tag: <pkg>@<version>" lines that changesets/action v1.9.0 scraped to learn which packages were published. The action therefore saw zero published packages: it pushed no git tags, created no GitHub releases, and set published=false -- while npm publishing itself succeeded. 3.6.0 reached npm with no GitHub release history because of this, and the publish step still reported success. Two v3 breaking changes combined to produce the failed run: - Published-package detection moved from stdout parsing to a shared output file named by CHANGESETS_OUTPUT (changesets/action#678). Action v1 has no such support and reported published=false, which skipped tagging and releases and also un-gated the canary step below. - `changeset version` now exits 1 when there are no unreleased changesets (changesets/changesets#1860); v2 exited 0 silently. That turned the un-gated canary step into a hard job failure. Upstream treats these as a matched pair and action v2 validates it, refusing CLI v2 (changesets/action#699). There is no equivalent check in v1 for CLI v3, which is why the mismatch degraded silently instead of failing fast. Changes: - changesets/action v1.9.0 -> v2.1.2, using v2's renamed kebab-case inputs and passing the app token through the `github-token` input, which is now required for custom tokens. `commitMode: github-api` is dropped because v2 uses the GitHub API by default. - Guard both canary steps on the presence of changeset files, so an emptied .changeset/ is a clean skip rather than exit 1. - Add a step asserting that the version present on npm has a matching git tag, so a silent tagging failure fails the job instead of reporting success. - Remove scripts/print_release_version.sh and its step. Its output was read nowhere in the workflow, its exit code was swallowed by the surrounding command substitution, and it ran `changeset version` followed by `git reset --hard` inside the release job. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * ci(release): trim the comments added with the changesets v2 upgrade The explanatory blocks restated the commit message and PR description, which git blame already reaches, and ran six to eight lines in a file whose idiom is one- to three-line constraint notes. Keep only what is not visible in the code and would be re-broken if removed: that the action and CLI majors move together, that the tag check is deliberately independent of the action's own report, and why the canary steps test for changeset files before versioning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.