chore(deps): bump changesets/action from 1.7.0 to 1.9.0#2260
Conversation
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
a860f11 to
9b37f55
Compare
There was a problem hiding this comment.
LGTM — routine Dependabot bump of changesets/action 1.7.0 → 1.9.0 with the SHA pin correctly matching the v1.9.0 release commit.
Extended reasoning...
Overview
This PR touches a single file, .github/workflows/release.yml, updating the SHA-pinned changesets/action reference from 6a0a831 (v1.7.0) to a45c4d5 (v1.9.0) in both the version-PR step and the publish step. The pinned SHA matches the v1.9.0 release commit listed in the upstream changelog/commit list, and the # v1 version comment remains accurate.
Security risks
The change is in the release workflow, which is supply-chain-sensitive (it has contents: write, pull-requests: write, and id-token: write for npm OIDC publishing). However, the action remains pinned to a full commit SHA from the official changesets/action repository, the upstream 1.8.0/1.9.0 changes are additive (new optional sub-actions, draft-PR input, and bug fixes) and do not alter the publish path used here (publish: pnpm run ci:publish), and no permissions or secrets are changed. No new tokens or scopes are required per the action's docs.
Level of scrutiny
This is a mechanical, Dependabot-style dependency bump following the repo's established SHA-pinning convention. Per the repo review conventions' CI guidance, no claims of breakage should be made without verification, and none are warranted — the workflow inputs used (publish, GITHUB_TOKEN, NPM_CONFIG_PROVENANCE) are unchanged between 1.7.0 and 1.9.0.
Other factors
The bug-hunting system found no issues, the timeline contains only standard bot comments (changeset-bot correctly notes no changeset is needed for a workflow-only change), and both usages of the action were updated consistently.
9b37f55 to
033df55
Compare
There was a problem hiding this comment.
LGTM — straightforward Dependabot bump of changesets/action from 1.7.0 to 1.9.0, SHA-pinned to the v1.9.0 release commit.
Extended reasoning...
Overview
This PR only touches .github/workflows/release.yml, updating the pinned SHA for changesets/action in two steps (the Version Packages PR step and the Publish step) from 6a0a831 (v1.7.0) to a45c4d5, which the Dependabot-provided commit list confirms is the v1.9.0 release commit. No other workflow inputs, permissions, or env vars change.
Security risks
Minimal. The action remains pinned to a full commit SHA (not a mutable tag), so supply-chain exposure is unchanged. The 1.8/1.9 changes are additive (new opt-in sub-actions for PR comments/status, draft-PR support) plus patch fixes; none alter the default version/publish behavior this workflow relies on, and no new permissions or tokens are required. The workflow already grants contents: write / pull-requests: write (version job) and id-token: write (publish job), which covers everything the bumped action does here.
Level of scrutiny
Low — this is a routine, mechanical CI dependency bump within the same major version, the kind of change Dependabot produces regularly. It does not touch SDK source, protocol logic, or any published package (changeset-bot correctly notes no changeset is needed).
Other factors
The bug-hunting system found no issues, and the same commit appears to already be present at the repository HEAD. Per the repo's review conventions on CI/GitHub Actions changes, I verified the new SHA against the release notes rather than asserting behavior from memory; nothing in the 1.7.0→1.9.0 changelog affects this workflow's existing configuration.
033df55 to
3a7e192
Compare
There was a problem hiding this comment.
LGTM — routine Dependabot bump of changesets/action to v1.9.0, both pinned SHAs updated consistently.
Extended reasoning...
Overview
This PR touches a single file, .github/workflows/release.yml, updating the SHA-pinned changesets/action reference from 6a0a831 (v1.7.0) to a45c4d5 (v1.9.0) in both places it is used (the version PR step and the publish step). The new SHA matches the v1.9.0 release commit listed in the Dependabot description, and both call sites are updated consistently so there is no version skew within the workflow.
Security risks
The action remains pinned to a full commit SHA (good supply-chain hygiene), and the upgrade is a minor/patch-level change within the v1 line. The new pr-comment/pr-status sub-actions introduced in 1.9.0 are opt-in and not used here, so no new permissions are needed; the existing contents: write / pull-requests: write and id-token: write grants are unchanged. The publish job continues to use the same pnpm run ci:publish command and OIDC/provenance setup.
Level of scrutiny
This is CI configuration touching the release pipeline, which warrants a quick sanity check rather than deep review: the change is mechanical (a Dependabot SHA bump with no input/permission changes), follows the established pinning convention, and the 1.7.0→1.9.0 changelog contains only additive sub-actions and bug fixes — no breaking changes to the inputs (publish) or outputs (hasChangesets) this workflow relies on.
Other factors
No bugs were found by the bug hunting system, no human reviewer comments are outstanding, and no changeset is needed for a workflow-only change. The actual release behavior will be exercised on the next merge to main, which is the normal validation path for this kind of bump.
3a7e192 to
ff42fdb
Compare
There was a problem hiding this comment.
LGTM — straightforward Dependabot bump of changesets/action to v1.9.0, with both pinned SHAs in release.yml updated consistently.
Extended reasoning...
Overview
This PR touches a single file, .github/workflows/release.yml, updating the pinned commit SHA for changesets/action from 6a0a831 (v1.7.0) to a45c4d5 (v1.9.0) at both usage sites (the Version Packages PR step and the Publish step). The Dependabot-provided commit list confirms a45c4d5 is the v1.9.0 tag commit, and the # v1 pin comment remains accurate.
Security risks
Minimal. The action remains pinned by full commit SHA (good supply-chain practice), and no permissions, tokens, or secrets are added or changed in the workflow. The v1.9.0 release notes describe additive sub-actions and patch fixes; the existing usage (default version step + publish: pnpm run ci:publish) requires no input changes.
Level of scrutiny
This is CI/release tooling, so it only affects the publish pipeline, not shipped SDK code. Per the repo's review conventions for .github/workflows/ diffs, I checked the changelog rather than asserting behavior from memory: nothing in 1.8.0/1.9.0 changes the inputs or permissions this workflow relies on.
Other factors
No bugs were found by the bug hunting system, and the only timeline activity is the standard changeset-bot and pkg-pr-new bot comments. The change is mechanical and consistent with how other action bumps are handled in this repo.
Bumps [changesets/action](https://github.com/changesets/action) from 1.7.0 to 1.9.0. - [Release notes](https://github.com/changesets/action/releases) - [Changelog](https://github.com/changesets/action/blob/main/CHANGELOG.md) - [Commits](changesets/action@6a0a831...a45c4d5) --- updated-dependencies: - dependency-name: changesets/action dependency-version: 1.9.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
ff42fdb to
4ef817f
Compare
There was a problem hiding this comment.
LGTM — straightforward Dependabot bump of changesets/action from 1.7.0 to 1.9.0, applied consistently to both pinned usages.
Extended reasoning...
Overview
This PR updates the changesets/action GitHub Action from 1.7.0 (6a0a831) to 1.9.0 (a45c4d5) in .github/workflows/release.yml. Both occurrences (the Version Packages PR step and the Publish step) are updated to the same SHA, which matches the v1.9.0 tag per the upstream release commit list in the PR description. No other workflow inputs, permissions, or env vars are changed.
Security risks
Low. The action remains pinned to a full commit SHA (not a mutable tag), which preserves supply-chain protection. The 1.8.0/1.9.0 changes are additive (new optional sub-actions pr-comment/pr-status, draft-PR support) plus patch fixes; none alter the default behavior of the version/publish flows used here, and no new permissions or tokens are required. The publish job's existing id-token: write / OIDC trusted-publishing setup is untouched.
Level of scrutiny
This is a CI configuration dependency bump generated by Dependabot — mechanical, small, and self-contained. The main risks for such bumps are (a) SHA not matching the claimed version and (b) only one of multiple usages being updated; both check out here. Per the repo's review conventions, no unverified claims about the action's behavior are being made.
Other factors
The bug-hunting system found no issues, and there are no outstanding reviewer comments. No changeset is needed since this only touches CI. The release workflow itself will exercise the new version on the next push to main; any breakage would surface immediately and be trivially revertible.
There was a problem hiding this comment.
LGTM — routine Dependabot bump of changesets/action from 1.7.0 to 1.9.0, with the pinned SHA matching the upstream v1.9.0 release commit and both usages in the workflow updated consistently.
Extended reasoning...
Overview
This PR is a Dependabot dependency bump touching only .github/workflows/release.yml. It updates the pinned commit SHA for changesets/action from 6a0a831f (v1.7.0) to a45c4d59 (v1.9.0) in both places the action is used (the Version Packages PR step and the Publish step). The new SHA matches the v1.9.0 release commit listed in the upstream repository's commit history included in the PR description.
Security risks
Minimal. The action remains SHA-pinned (not a mutable tag), which preserves supply-chain integrity — the update simply moves the pin to the upstream v1.9.0 release commit. The 1.8.0/1.9.0 changes are additive (new sub-actions, draft-PR input) plus patch fixes; none alter the token handling or publish flow used by this workflow. Existing permissions (contents: write, pull-requests: write for versioning; id-token: write for OIDC publish) are unchanged and sufficient.
Level of scrutiny
This touches the release/publish pipeline, which warrants some care, but the change itself is a mechanical, SHA-pinned minor version bump of a widely used first-party changesets action, with no configuration or input changes. Per the repo's review conventions on CI/GitHub Actions diffs, no unverified failure claims apply here, and the workflow inputs (publish: pnpm run ci:publish, GITHUB_TOKEN, NPM_CONFIG_PROVENANCE) are untouched and remain compatible with 1.9.0.
Other factors
No changeset is needed since this doesn't affect published packages. No bugs were found by the bug-hunting system, and there are no outstanding reviewer comments. Both usages of the action were updated consistently, so there is no partial-migration concern.
Bumps changesets/action from 1.7.0 to 1.9.0.
Release notes
Sourced from changesets/action's releases.
Changelog
Sourced from changesets/action's changelog.
... (truncated)
Commits
a45c4d5v1.9.0b459b1eVersion Packages (#637)f9585d9Update@changesets/ghcommit(#645)020e8ccUse internal bot for versioning (#643)b072bccAdd simple PR comment sub-action (#636)8795eeeComment changeset status in PRs (#625)34f64f6Fixed an issue with GitHub releases not being created for successfully publis...1d54b9eSimplify getChangelogEntry (#632)031358fUpdate to typescript v6 (#633)a0c05f7Bump@changesets/changelog-githubfrom 0.5.2 to 0.7.0 (#620)