-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Changesets #10337
Introduce Changesets #10337
Conversation
@@ -29,6 +29,25 @@ jobs: | |||
- store_artifacts: | |||
path: reports/junit | |||
|
|||
# Ensure that any PR that changes packages has a changeset on it (perhaps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An example of a PR with a failing changesets check: apollographql/apollo-server#7229
You can simply only have the check fail on release branches?
Note that there's kinda two things here (I suspect you understand this but maybe this will be helpful for others):
|
Agree - I was more referring to the fact that while the
Glad you brought up these points as they're important to note :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So exciting! 🚀
I have no specific feedback about the settings there, they all look sensible to me
|
@alessbell I agree. The more we can protect ourselves, the better. Mistakes happen and the more we can prevent them, the better. Nice work getting this in there! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯 💯 💯 🔥 🔥 🔥
This is such a positive change. Thanks so much for getting this in there!
This PR introduces a
.changeset/config.json
and three GitHub workflows to begin the process of automating releases of@apollo/client
🎉Prereleases
In
.github/workflows/prerelease.yml
, pushes torelease-*
integration branches typically used for assembling minor releases cause the branch to enter changeset's prerelease mode which creates a.changeset/pre.json
file.Each commit to a release branch that contains a changeset (created on the feature branch before merging into the release branch via
npx changeset
) will create a new branch prefixed withchangeset-release/
and open an automated PR that looks like this:The
changeset-release/*
PR contains a diff that:pre.json
In this example, merging the automatically created PR will release version
1.4.0-alpha.2
at thealpha
tag only on npm (we intentionally do not create GitHub releases for alphas) 🚀Again, commits that do not add new changesets will not trigger an automated PR. When work on our release branch is completed, the next step is to exit prerelease mode.
Exiting Prerelease mode
Changeset has an API for exiting prerelease mode that doesn't quite fit our workflow, so I've taken a different approach in
.github/workflows/exitPrerelease.yml
. The problem withchangeset pre exit
is that it sets"mode": "exit"
inpre.json
, but leaves the file in place to be merged into the default branch, wherechangeset version
would theoretically later get run (unless it's being run manually, which seems to defeat the purpose).This would lead to
pre.json
being repeatedly committed and removed from themain
branch, and I'm of the opinion that we want to avoid the possibility ofmain
ever being inpre
mode, so we should avoid merging the file altogether.Instead,
.github/workflows/exitPrerelease.yml
can be run via GitHub actions UI using the workflow dispatch API:In our example, if we were to enter
"release-1.4"
, the following changes would be be committed to our release branch:pre.json
is removed and the version inpackage.json
reverts to the last release frommain
. This leaves our changesets to be committed tomain
where our.github/workflows/release.yml
workflow will pick them up and open an automated PR for the release, just as if we had committed a patch changeset directly tomain
.Releases
Changesets that are merged into
main
trigger an automated PR, just as on the release branch, but merging these PRs create:next
tagA few things to note
next
at which point we can run e.g.npm dist-tag add @apollo/client@3.8.0 latest
locally to promote it tolatest
, but we can opt to release straight tolatest
in the future.We can add a check to make sureThis has been added in a727a56.pre.json
doesn't get committed tomain
, but the downside is that release branches will appear to be failing their status checks until we exit prerelease mode.CHANGELOG.md
and we can remove them if we like (see Apollo Server example and @glasser's commit ttps://github.com/apollographql/apollo-server/pull/7017).