Skip to content

chore(deps): bump changesets/action from 1.9.0 to 2.1.2 #3013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −2
Open

chore(deps): bump changesets/action from 1.9.0 to 2.1.2 #3013

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ jobs:

- name: Create or update Version Packages PR
id: changesets
uses: changesets/action@a45c4d594aa4e2c509dc14a9f2b3b67ba3780d0d # v1
uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1
Comment on lines 42 to +45

@claude claude Bot Oct 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Maintainers lose npm publishing after a Version Packages PR merges: the Publish job is skipped on every push to main instead of running. The PR's own changelog says v2.0.0 renamed the root action's outputs to the sub-actions' kebab-case convention, so the v2 action pinned at release.yml:45 emits has-changesets, not hasChangesets. The job output at release.yml:18 therefore reads an empty string, and the condition at release.yml:53 (== 'false') is never true. Fix: read the v2 output name (steps.changesets.outputs.has-changesets) at release.yml:18, and check every other steps.changesets.outputs.* reference against the v2 action.yml; this is separate from the renamed publish input at release.yml:86. [also at: .github/workflows/release.yml:18 - If v2 renamed the root action's outputs along with its inputs, the Publish job is silently skipped on every push to main after this merges. release.yml:18 exports steps.changesets.outputs.hasChangesets from the new v2.1.2 pin at release.yml:45, and the Publish job's gate at release.yml:53 only runs when that value is the string 'false'.]

Why this was flagged

Trigger: any push to main (release.yml:3-6), which runs the version job. The version step at release.yml:45 now runs changesets/action at ae32849d5ba541f9ae29e40e22a623bc13562f51; the quoted v2.0.0 changelog (#681) says the root action's inputs and outputs were renamed to match the sub-actions' conventions, which are kebab-case, so the output is has-changesets. release.yml:18 still maps steps.changesets.outputs.hasChangesets, which under v2 is an unset output and evaluates to ''. release.yml:53 gates the publish job on needs.version.outputs.hasChangesets == 'false'; '' == 'false' is false, so the Publish job is skipped on every run, including the run right after a Version Packages PR merges. On the base branch v1 emits hasChangesets, the condition evaluates true when no changesets are pending, and the publish job runs. This is independent of the already-filed publish -> publish-script rename at release.yml:86: fixing that input alone still leaves the job skipped by this condition.

Verification: release.yml:18 exports hasChangesets: ${{ steps.changesets.outputs.hasChangesets }} from the step at release.yml:43-47, and release.yml:53 gates the Publish job on needs.version.outputs.hasChangesets == 'false'. If the v2 action no longer emits the camelCase hasChangesets output, the job output is the empty string, '' == 'false' is never true, and the Publish job (release.yml:49-89) is skipped on every push.

@claude claude Bot Oct 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 nit (optional): .github/workflows/release.yml — CLAUDE.md says comments say what the code does: both changed uses: lines pin a new SHA that the PR itself describes as changesets/action v2.1.2, yet the trailing # v1 version comment is left unchanged, so the comment no longer describes the commit being pinned. Fix: update the trailing comment to the tag the SHA actually resolves to (# v2.1.2), or keep the v1 pin if v2 is not intended; this covers the 2 sites listed. Same instruction at 2 sites (.github/workflows/release.yml:45, .github/workflows/release.yml:84).

Why this was flagged

Nothing fails at runtime from the comment itself. The # v1 tag comment is the only human-readable record of which action version a bare SHA pins; readers (and SHA-pin tooling that trusts the comment) will believe the workflow still runs changesets/action v1 while, per the Dependabot description, the SHA ae32849d is v2.1.2. This matters here because the PR's own release notes say v2.0.0 renamed the root inputs (publish -> publish-script, etc.) and stopped treating the GITHUB_TOKEN env var as a substitute for the explicit github-token input for API pushes; the workflow still passes with: publish: and only env: GITHUB_TOKEN, so a reader trusting # v1 would not know to check those. I could not resolve the SHA locally (shallow clone, no network), so the version claim rests on the PR description; the stale-comment mismatch is certain either way since the pin changed and the comment did not.

Verification: CLAUDE.md (base 9bc40e9) principle 6 reads verbatim: "The words are true — Changesets, docs and comments say what the code does." The diff changes .github/workflows/release.yml:45 and :84 to uses: changesets/action@ ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1, swapping the pinned SHA while leaving the trailing # v1 comment, yet the PR title and Dependabot release notes identify that SHA as changesets/action 2.1.2 (a major bump that renamed the root inputs publish -> publish-script and changed token handling), so the comment no longer describes the commit the line pins.

env:
GITHUB_TOKEN: ${{ github.token }}

Expand Down Expand Up @@ -81,7 +81,7 @@ jobs:
run: npm install -g npm@11.5.1

- name: Publish to npm
uses: changesets/action@a45c4d594aa4e2c509dc14a9f2b3b67ba3780d0d # v1
uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1
with:
publish: pnpm run ci:publish
Comment on lines +84 to 86

@claude claude Bot Oct 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Releases stop publishing to npm after this merges: the publish job runs the action without any publish script, so no package is pushed. The PR bumps changesets/action from v1 to v2.1.2, and v2.0.0 renamed the root action input publish to publish-script, so publish: pnpm run ci:publish at release.yml:86 becomes an unknown input the action ignores. Fix: either keep the pin on the v1 line, or complete the v2 migration in this file: rename the input to publish-script, check the v2 output name used at release.yml:18 and release.yml:53 (hasChangesets), and update the # v1 comments on lines 45 and 84.

Why this was flagged

On every push to main, the publish job at release.yml:49 runs changesets/action pinned to ae32849d5ba541f9ae29e40e22a623bc13562f51 (release.yml:84), which the PR states is v2.1.2. The PR's own release notes for v2.0.0 (#681) say the root input publish was renamed to publish-script. The workflow still passes publish: pnpm run ci:publish (release.yml:86), so GitHub Actions warns of an unexpected input and the action runs with no publish script, meaning pnpm changeset publish from package.json:39 is never executed and nothing is published to npm. On the base branch the v1 action honours publish and publishes. If v2 also renamed the hasChangesets output read at release.yml:18, the condition at release.yml:53 compares an empty string to 'false' and the publish job never runs at all, which fails the same way. The # v1 comments on release.yml:45 and release.yml:84 hide that the pin crossed a major version with breaking renames. The SHA cannot be resolved in this shallow checkout, so this rests on the PR's stated version.

Verification: The diff only swaps the SHA (release.yml:45 and :84) and leaves the publish step's input untouched (release.yml:86). changesets/action v2.0.0 renamed publish -> publish-script, so on v2 publish is an undeclared input: GitHub emits "Unexpected input(s) 'publish'" and the action runs with no publish script, so nothing is published to npm while the workflow reports green.

env:
Expand Down
Loading