To read about what happens during a production deployment, see the release process deep dive doc.
To initiate a new production deployment:
script/release vX.Y.ZSee script/release --help for more information.
Note
Deployment workflow requires maintainer approval to run.
What this does is:
- Builds Linux binaries on Ubuntu;
- Builds and signs Windows binaries on Windows;
- Builds, signs, and notarizes macOS binaries on macOS;
- Uploads all release artifacts to a new GitHub Release;
- A new git tag
vX.Y.Zis created in the remote repository; - The changelog is generated from the list of merged pull requests;
- Updates GitHub CLI marketing site with the contents of the new release;
- Updates the
ghHomebrew formula in thehomebrew/homebrew-corerepo.
Note
Homebrew/formulae.brew.sh makes new formula versions available every 15 minutes through scheduled CI workflow.
For more information, see https://docs.brew.sh/Formula-Cookbook#an-introduction
To test out the build system while avoiding creating an actual release:
script/release --staging vX.Y.Z --branch patch-1 -p macosThe build artifacts will be available via gh run download <RUN> -n macos.
- Features to be released should be reviewed and approved at least one day prior to the release.
- Feature releases should bump up the minor version number.
- Breaking releases should bump up the major version number. These should generally be rare.
A local release can be created for testing without creating anything official on the release page.
- Make sure GoReleaser is installed:
brew install goreleaser script/release --local- Find the built products under
dist/.
Occasionally, it might be necessary to clean up a bad release and re-release.
- Delete the release and associated tag
- Re-release and monitor the workflow run logs
- Open pull request updating
ghHomebrew formula with new SHA versions, linking the previous PR - Verify resulting Debian and RPM packages, Homebrew formula