ci(release): make the Changesets version PR pass its own required checks

[chappie-daemon]

Description

Makes the Changesets version PR able to pass its own required checks, so a release no longer needs a human to push into the bot's branch before it can merge.

• .changeset/config.json points commit at scripts/changeset-commit-message.cjs, which writes chore: release <package>@<version> for the version commit instead of RELEASING: Releasing N package(s), and no longer appends [skip ci]. changeset add keeps the stock docs(changeset): <summary> subject, and the documented skipCI option is still honoured.
• .github/workflows/changesets.yml passes RELEASE_PAT to actions/checkout. The version-branch push is currently authenticated with the credential the checkout persisted — the default GITHUB_TOKEN — and GitHub starts no workflow runs for events a GITHUB_TOKEN creates. The action's own .netrc does receive RELEASE_PAT, but the checkout's http.extraheader answers first, so the request never falls back to it.
• test/unit/ci/changesets-commit-message.spec.ts asserts the contract that broke: a conventional subject, no [skip ci], only released packages in the subject, skipCI still honoured. It fails against the status quo.
• .changeset/release-ci-triggering.md — an empty changeset, which CONTRIBUTING calls for on a CI-only change.

No production source is touched, and nothing about what a release publishes changes: the version commit's tree is identical, only its message and the credential behind the push differ.

Related Issue

Closes #790

Motivation and Context

Every release needs a human today. gh pr merge on the version PR refuses with

{"message":"Repository rule violations found\n\n6 of 6 required status checks are expected.\n\n","status":405}

because no event=pull_request run ever exists for the head the action pushes. Two independent suppressors are responsible, and both sit in that push:

• [skip ci] in the commit message makes GitHub skip both push and pull_request runs for the commit. The version branch keeps that message as its head, so reopening or editing the PR starts nothing either — only replacing the head with a [skip ci]-free commit does.
• GITHUB_TOKEN provenance: pushes made with the default token create no workflow runs at all.

Then, when the checks are forced to run, Lint commits fails on the same message — type must be lower-case [type-case] and type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum] for RELEASING:. It had only ever reported success because a workflow_dispatch run carries no pull request context and returns a vacuous pass.

How Has This Been Tested?

In a worktree at this branch, using the exact command CI runs (pnpm run changeset:version) with a real changeset, plus a negative control that reproduces the reported failure:

.changeset/config.json	commit message produced	[skip ci]	commitlint --from <base> --to HEAD
this branch	chore: release nostream@3.1.1	absent	pass
commit: true (status quo)	RELEASING: Releasing 1 package(s)	present	fail — type-case, type-enum

Changelog generation was disabled for the scratch version run only: @changesets/changelog-github needs real commit metadata from the GitHub API, is untouched here, and its network path is not what is under test — the commit message is.

Also run: pnpm run lint (pass, 471 files), pnpm run check:deps (pass), pnpm exec changeset status --since origin/main (pass — the changeset-check job's command), and the new spec twice (5 passing), then with commit: true (5 failing, each naming the config). The full unit and integration suites were not run locally; CI runs them.

Screenshots (if appropriate):

Not a UI change.

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• I added a changeset, or this is docs-only and I added an empty changeset.
• All new and existing tests passed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 453af6e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 0 packages

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[greptile-apps]

Confidence Score: 4/5

[High risk] Changes how release commits are created and signed in CI.

The PR appears safe to merge, with a non-blocking gap in regression coverage for the configured skipCI option.

Findings

1.  Configured skip option goes untested ▶

Summary

The PR configures a conventional, skip-free Changesets version commit and uses RELEASE_PAT for checkout so the version PR can trigger its required checks.

• Adds an empty changeset for the CI-only change.
• Adds commit-message tests; their no-skip assertions do not cover the configured options.

_{Reviews (1) · Last reviewed commit: "test(release): assert the version commit..."}

[coveralls]

coverage: 72.874%. remained the same — fix/release-ci-triggering into main