Repository navigation
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
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.
| run: pnpm test | ||
|
|
||
| - name: Test release automation | ||
| run: pnpm test:release |
There was a problem hiding this comment.
Could we leave this out of the release job? If these tests ever fail, for example after a package is added to the fixed group, npm publishing would be held up too. Running them in regular CI should be enough.
| # Retry GitHub release creation after all package tags have been pushed. | ||
| # Changesets can report published=false when npm is already up to date. | ||
| - name: Create combined GitHub release | ||
| if: steps.changesets.outputs.has-changesets == 'false' |
There was a problem hiding this comment.
What do you think about steps.changesets.outputs.published == 'true' here? Then the step only runs when something was actually published, and we wouldn't need the SHA check on every push to main.
| - name: Run tests | ||
| run: pnpm test | ||
|
|
||
| release-automation: |
There was a problem hiding this comment.
If the scripts get smaller, we could probably run the remaining tests as part of the existing test job instead of adding a separate one.
| } | ||
| } | ||
|
|
||
| async function api(endpoint, body) { |
There was a problem hiding this comment.
Since gh is available on the runner with GH_TOKEN, we could use gh release view / gh release create --verify-tag here instead. That would also let us drop the request mocks in the tests.
| throw new Error('GITHUB_REPOSITORY, GITHUB_SHA and GH_TOKEN are required'); | ||
| } | ||
|
|
||
| for (const published of publishedPackages) { |
There was a problem hiding this comment.
This check runs after publishing, so if it ever triggers, the packages are already on npm. I think it'd be fine to leave it out for now and add a policy when we have independently versioned packages.
| } catch (error) { | ||
| throw new Error(`${pkg.name}: ${error.message}`, { cause: error }); | ||
| } | ||
| if (entry) sections.push(`## ${pkg.name}@${pkg.version}\n\n${entry}`); |
There was a problem hiding this comment.
Small idea on the format: could we merge the entries into one list (grouped by change type), skip the Updated dependencies bullets, and de-duplicate changesets that touch several packages? Right now a changeset like #1476 in 5.4.1 would show up under both repack and plugin-reanimated. The single merged list would also match how the 5.4.x releases look today.
|
@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. |
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.