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.
This branch has not been deployed
2 participants
Summary
Changesets currently creates a GitHub release for every published package. Create one combined release on the existing main package tag instead, with notes collected from all packages in the fixed release group.
Validation
node --test .github/scripts/*.test.mjs— 18 tests passed, including 5.4.2 notes, one release for six packages, existing releases, and retry behavior..github/scriptsandpackage.json— passed.git diff --check— passed.Scope
This covers the current fixed group containing
@callstack/repack. Missing or mismatched package tags require manual verification and repair before retrying; the script does not recover npm publications or recreate tags. Canary publishing is unchanged.