Current State
The release pipeline in .github/workflows/release.yml triggers a publish only when the merge into main introduces at least one .changeset/*.md file. The detector uses a grep on HEAD~1 HEAD.
This forces the release engineer to leave .changeset/.md unconsumed in the release branch. If the changesets were already consumed locally (pnpm changeset version edited package.json and CHANGELOG.md, and removed the .changeset/.md files), the merge contains no changesets and the workflow becomes a no-op.
Located in: .github/workflows/release.yml step Detect pending changesets.
Problems with current implementation:
- The detector misses the documented consume-then-merge flow.
- A second patch bump is forced when recovery is attempted via a post-merge changeset, breaking the planned version number.
- The 1.3.0 release shipped as 1.3.2 because of this.
Proposed State
Accept a manual version bump as a publish trigger, in addition to a fresh .changeset/*.md. Change the detector to:
- name: Detect pending changesets
id: detect
echo "has_changesets=true" >> "$GITHUB_OUTPUT"
else
echo "has_changesets=false" >> "$GITHUB_OUTPUT"
fi
Expected improvements:
- Recovery path for accidental no-op merges.
- No forced extra patch bump on the next release.
- Removes the need for an artificial .changeset/*.md post-merge.
Motivation
Every release that consumes changesets locally becomes a debugging session. Future releases will keep derailing the version number unless the detector is fixed.
Risks
- Risk 1: a package.json diff could trigger publish for unrelated reasons.
- Mitigation: add a second check on "version": field change.
- Risk 2: combined condition could fire twice for the same release.
- Mitigation: skip publish when latest tag matches the current version.
- Risk 3: hardcoded path to packages/errors may break as monorepo grows.
- Mitigation: parametrize via workflow input or pnpm changeset status --json.
Migration Plan
- Open a PR fix/release-detect-manual-bumps.
- Update Detect pending changesets to use the combined regex.
- Add the version-bump-dedup guard at the top of Publish packages.
- Test with workflow_dispatch on a throwaway branch.
Rollback plan: revert the PR.
Backward Compatibility
Scope
Files/folders affected:
- .github/workflows/release.yml
Out of scope:
- .changeset configuration.
- The release engineer runbook (covered by a follow-up docs issue).
Component(s) Affected
Priority
p1: High
Estimated Effort
effort: s - Half a day
Test Coverage Requirements
Verification: workflow_dispatch on test branches mimicking both shapes (changeset present vs version bumped).
Testing Approach
- Create test/manual-bump-detect off main.
- Cherry-pick one feature commit, run pnpm changeset version locally, commit the bump.
- Open a PR, observe CI.
- Merge. Release workflow should publish.
- Revert. Repeat with no-changeset, no-version-bump PR. Should no-op cleanly.
Related Issues / Pull Requests
Relevant Documentation
- docs/internal/engineering/plans/release-system.md
- docs/internal/engineering/process/releasing-a-new-version.md
- .github/workflows/release.yml
Pre-Submission Checklist
Current State
The release pipeline in .github/workflows/release.yml triggers a publish only when the merge into main introduces at least one .changeset/*.md file. The detector uses a grep on HEAD~1 HEAD.
This forces the release engineer to leave .changeset/.md unconsumed in the release branch. If the changesets were already consumed locally (pnpm changeset version edited package.json and CHANGELOG.md, and removed the .changeset/.md files), the merge contains no changesets and the workflow becomes a no-op.
Located in: .github/workflows/release.yml step Detect pending changesets.
Problems with current implementation:
Proposed State
Accept a manual version bump as a publish trigger, in addition to a fresh .changeset/*.md. Change the detector to:
id: detect
echo "has_changesets=true" >> "$GITHUB_OUTPUT"
else
echo "has_changesets=false" >> "$GITHUB_OUTPUT"
fi
Expected improvements:
Motivation
Every release that consumes changesets locally becomes a debugging session. Future releases will keep derailing the version number unless the detector is fixed.
Risks
Migration Plan
Rollback plan: revert the PR.
Backward Compatibility
Scope
Files/folders affected:
Out of scope:
Component(s) Affected
Priority
p1: High
Estimated Effort
effort: s - Half a day
Test Coverage Requirements
Verification: workflow_dispatch on test branches mimicking both shapes (changeset present vs version bumped).
Testing Approach
Related Issues / Pull Requests
Relevant Documentation
Pre-Submission Checklist