Repository navigation
fix: publish one combined GitHub release - #1503
Conversation
|
@ArekChr is attempting to deploy a commit to the Callstack Team on Vercel. A member of the Team first needs to authorize it. |
|
dannyhw
left a comment
There was a problem hiding this comment.
I tested the branch locally: all 18 tests pass, and --dry-run produces a single release on @callstack/repack@5.4.2, titled 5.4.2. The output looks good.
I have a few suggestions to make this lighter to maintain, since we only touch release tooling every now and then:
- Keep the changesets config as it is.
create-github-releases: falsewithpush-git-tags: truelooks right to me. - Have
release-notes.mjsprint the notes to stdout. The workflow could then create the release withgh, which is already authenticated on the runner. That could let us dropcreate-release.mjs. Something like:
- name: Create GitHub release
if: steps.changesets.outputs.published == 'true'
run: |
version=$(node -p "require('./packages/repack/package.json').version")
tag="@callstack/repack@${version}"
node .github/scripts/release-notes.mjs > release-notes.md
gh release view "$tag" >/dev/null 2>&1 || gh release create "$tag" \
--verify-tag \
--title "$version" \
--notes-file release-notes.md \
$([[ "$version" == *-* ]] && echo --prerelease)
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}- Trim the tests. A couple of tests for the CHANGELOG extraction against the 5.4.2 fixture would give us good coverage. Then we wouldn't need the separate CI job or the test step before publishing.
On retries: if you'd like to keep the automatic retry after a failed release step, the "main tag points at GITHUB_SHA" check could be a single gh api repos/$GITHUB_REPOSITORY/commits/$tag --jq .sha comparison in the same step. I'm also happy to just create the release manually in that rare case, whichever you prefer.
|
@dannyhw Thanks for testing this! I’ve addressed your suggestions, the workflow now uses gh, and the notes are merged by change type, without duplicates or dependency updates. I also reduced the tests and moved them into the existing CI job. For failed release creation, I kept manual recovery and documented the steps. All four tests pass locally, along with Biome and actionlint. |
…otes Match version headings only at column 0, since Changesets indents changeset bodies by two spaces. A heading such as `## Migration` in a changeset no longer cuts off the package's notes, and an unclosed code fence no longer pulls in older versions. List a changeset once under its highest change type when it bumps packages by different types.
Changesets currently creates a GitHub release for every published package. This creates one combined release on the existing main package tag (for example,
@callstack/repack@5.4.2), titled with the shared version.The notes list the fixed release group and merge its changelog entries by change type, remove dependency update bullets, and deduplicate shared entries. The generator prints Markdown to stdout; the workflow uses
gh release create --verify-tagonly after Changesets publishes packages and leaves existing releases untouched. Changesets still manages npm publishing and package tags.The remaining generator tests run in the existing CI test job. CONTRIBUTING.md documents previewing notes and manually creating a missing GitHub release after npm publication. Canary publishing is unchanged.
Validation:
.github/scriptsandpackage.json, actionlint 1.7.7 for both changed workflows, andgit diff --checkpassed.