pnpm-release-changeset.yml passes changesets/action v1 input names to @v2.0.0 — publishing silently never runs

[unional]

Description

.github/workflows/pnpm-release-changeset.yml pins changesets/action@v2.0.0 but still passes the v1 input names. changesets/action@v2.0.0 renamed every one of them:

Passed by the workflow (v1)	Actual v2.0.0 input
version	version-script
publish	publish-script
commit	commit-message
title	pr-title

GitHub Actions does not fail on unknown with: keys — it ignores them. So the action runs with all three of these unset, and falls back to its defaults.

The consequential one is publish-script. When it is unset, the action only ever creates/updates a version PR and never publishes to npm. There is no error; the job goes green. A release would appear to succeed while nothing is published.

Secondary effects:

• version-script unset falls back to the built-in changeset version, bypassing pnpm run version. Benign for consumers whose version script is just changeset version, but it is no longer the repo's own script.
• commit-message unset falls back to Version Packages instead of the intended chore: version packages.

Additional concern: token and permissions

changesets/action@v2.0.0 pushes release commits and tags through the GitHub API by default (push-with-git-cli defaults to false), authenticated by the github-token input, which defaults to ${{ github.token }}.

The workflow supplies its custom token only as the GITHUB_TOKEN environment variable (secrets.CI_GITHUB_TOKEN), not as the github-token input. Under v2 that env var is not what the action authenticates with, so the custom token is effectively ignored.

That matters because the job declares permissions: contents: read, while pushing commits and tags requires contents: write. Worth verifying both together when fixing the input names.

Also: changesets/action@v2 requires Changesets CLI v3

v2.0.0's release notes state it updates to Changesets v3 packages, and it validates the consumer's CLI version, directing CLI v2 users to changesets/action@v1.

Any repo using this reusable workflow while still on @changesets/cli v2 is therefore already mismatched. repobuddy/repobuddy is upgrading to @changesets/cli v3 now, which resolves that half — but the renamed inputs above are independent of the CLI version and still need fixing here.

Expected Behavior

The reusable workflow invokes changesets/action@v2.0.0 with the input names that version actually accepts, so pnpm run release runs and packages publish.

Actual Behavior

publish-script is never set, so the publish step does not run. The workflow reports success without publishing.

Suggested Fix

- uses: changesets/action@v2.0.0
  with:
    github-token: ${{ secrets.CI_GITHUB_TOKEN }}
    commit-message: 'chore: version packages'
    version-script: pnpm run version
    publish-script: pnpm run release

plus raising the job's permissions to contents: write (keeping id-token: write).

Notes

Found while upgrading repobuddy/repobuddy to @changesets/cli v3. That repo consumes this reusable workflow but cannot change it, so recording the coupling here before the upgrade lands.

[unional]

Fix opened in #44 (not merged).

All three defects addressed: the four v2 input names, the custom token moved to the github-token input, and permissions raised to contents: write with id-token: write kept.

Verified against changesets/action@v2.0.0's own action.yml at the pinned tag rather than from this issue's table — every input name confirmed present, and push-with-git-cli does default to false. The analysis here held up exactly.

Two things worth adding to the record:

actionlint cannot catch this class of bug. I ran it against the unfixed file as a control and it passed, exit 0 — it does not validate third-party action input names. Green lint was never going to flag this.

The root cause sits upstream of this issue and is still live. .mergify.yml auto-merged the v1 → v2 major as #42 (branch renovate/changesets-action-2.x, merged 00:58Z 2026-08-12). The guard head~=^(?!major-) expects a major- branch prefix that Renovate does not produce here, so a major merged like a patch and reached every consumer instantly via @main. #44 fixes the consumer half by putting this repo on tags; the Mergify rule needs a separate fix.

Also relevant to closing this out: a full org scan found a fourth consumer that was not on the known list — repobuddy/jest-watch-toggle-config-2 — and that all four consumers are still on @changesets/cli v2 (^2.26.0, ^2.29.7, ^2.29.8, ^2.25.2). Since v2.0.0 hard-validates CLI v3 (changesets/action#699), none of them can use the fixed workflow until they upgrade. Migration issues are filed on each. #44's body raises the question of whether v1.0.0 should instead ship changesets/action@v1 so consumers can adopt it immediately — that is a call for the Council, not something I decided.

[unional]

Confirmed in a real run, with one correction to the report above.

repobuddy/repobuddy merged its @changesets/cli v3 upgrade, so main now exercises this workflow with CLI v3. Two things are now verified against actual logs.

1. The CLI v2 / action v2 mismatch was real, and is now cleared

Release runs on repobuddy/repobuddy@main were hard-failing before the upgrade (run 31574547701, 2026-08-12):

Error: This version of the Changesets action is designed to work with Changesets CLI v3.
Changesets CLI v2 is not supported; use Changesets action v1 instead, which is compatible with CLI v2.

That error is gone now that the consumer is on CLI v3.

2. Correction: the renamed inputs fail loudly, not silently

I wrote above that Actions ignores unknown with: keys, so publish-script would end up unset and the publish step would "silently never run" while the job went green. That is wrong. changesets/action@v2.0.0 explicitly validates the legacy input names and aborts. From run 31671851979 (2026-08-13):

##[warning]Unexpected input(s) 'commit', 'version', 'publish', valid inputs are
['github-token', 'publish-script', 'version-script', 'commit-message', 'pr-title',
 'pr-draft', 'pr-base-branch', 'create-github-releases', 'push-git-tags', 'push-with-git-cli']

##[error]Error: The following inputs have been renamed:
- "publish" -> "publish-script"
- "version" -> "version-script"
- "commit" -> "commit-mesage"
Please update your workflow file.

This is better news than the original report: there is no silent no-op release. The job fails outright, so a broken release cannot be mistaken for a successful one. The severity is unchanged though — releases are still blocked until this workflow is fixed, and repobuddy/repobuddy@main is red right now for exactly this reason.

Heads-up when applying the fix

The action's own error message contains a typo — it says "commit" -> "commit-mesage" (missing s). The actual accepted input per action.yml is commit-message. Don't copy the message verbatim.

The suggested fix in the issue body is otherwise unchanged and still correct.