Repository navigation
chore(deps): bump changesets/action from 1.9.0 to 2.1.2 - #3013
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [changesets/action](https://github.com/changesets/action) from 1.9.0 to 2.1.2. - [Release notes](https://github.com/changesets/action/releases) - [Changelog](https://github.com/changesets/action/blob/main/CHANGELOG.md) - [Commits](changesets/action@a45c4d5...ae32849) --- updated-dependencies: - dependency-name: changesets/action dependency-version: 2.1.2 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| - name: Create or update Version Packages PR | ||
| id: changesets | ||
| uses: changesets/action@a45c4d594aa4e2c509dc14a9f2b3b67ba3780d0d # v1 | ||
| uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1 |
There was a problem hiding this comment.
🔴 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.
| uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1 | ||
| with: | ||
| publish: pnpm run ci:publish |
There was a problem hiding this comment.
🔴 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.
| - name: Create or update Version Packages PR | ||
| id: changesets | ||
| uses: changesets/action@a45c4d594aa4e2c509dc14a9f2b3b67ba3780d0d # v1 | ||
| uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v1 |
There was a problem hiding this comment.
🟡 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.
claude
Bot
added
the
v2
Bumps changesets/action from 1.9.0 to 2.1.2.
Release notes
Sourced from changesets/action's releases.
... (truncated)
Changelog
Sourced from changesets/action's changelog.
... (truncated)
Commits
ae32849v2.1.20138f45Version Packages (#726)8833883Handle error when pushing git tags with the git CLI (#735)e08fde7Improve log messages (#730)371fd77Bump human-id in the production-dependencies group across 1 directory (#732)85efcafBump actions/checkout in the github-actions group across 1 directory (#734)5bb9d5cBump the development-dependencies group across 1 directory with 7 updates (#733)ca85897Always prepare branch for version (#729)36f529fFix root action double error logs (#724)d7669c8Version Packages (#722)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)