Release automation script #10449
Draft
Release automation script #10449
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Without this, Sphinx refuses to use the "-b markdown" builder (see next commit).
We provide releases in several different formats and channels. There are many manual steps involved in making a release. This makes it hard to learn or share improvements (especially share improvements that last once-and-for-all). Also there is potential for error -- for example our Debian PPAs don't include the latest release and our website doesn't link to the latest tarball. With our current approach, packaging tends to get more complicated, for example we'll want to add things like "Depends: librust-hexponent" to our Debian package, and set the version based on Cargo.toml. Add a script to automate the boring steps of the release process. This should obsolete most of https://github.com/fish-shell/fish-shell/wiki/Release-checklist It seems to work on my Linux system but it's obviously not battle-tested yet. The most essential TODO comments ones are for uploading Debian packages. Iteration on the script itself is usually quite fast. I run something like git add build_tools/release.sh git commit -m wip build_tools/release.sh 3.8.0 --dry-run --no-test # plus eventual --no-rebuild --no-rebuild-debs As a temporary hack, the Debian packages are currently built in a Docker container. It'd be easy to skip Docker when debmake is installed on the host system. We don't yet pass through gpg-agent into Docker, so the debuild process requires interactive password input. It takes a really long time (> 15 minutes) to build all Debian packages because we rebuild them sequentially for all Ubuntu releases (mantic, jammy, focal, bionic and xenial) even though only "debian/changelog" is different. For iterating on the script, we can use "--no-rebuild-debs" to reuse the the packages after they've been built once. Of course this is only valid if the tarball has not changed since. We could probably ask debuild to validate this, or speed up the process in a different way, at least parallelize. Future ideas: - we could run the script in CI instead, to keep us even more honest. - we should try to simplify the website release process (should not need to talk to the github API, the script already has enough information). - do something similar for the the macOS-specific parts
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We provide releases in several different formats and channels.
There are many manual steps involved in making a release.
This makes it hard to learn or share improvements (especially share improvements that last once-and-for-all).
Also there is potential for error -- for example our Debian PPAs don't include the latest release and our website doesn't link to the latest tarball.
With our current approach, packaging tends to get more complicated, for example we'll want to add things like "Depends: librust-hexponent" to our Debian package, and set the version based on Cargo.toml.
Add a script to automate the boring steps of the release process.
This should obsolete most of https://github.com/fish-shell/fish-shell/wiki/Release-checklist
It seems to work on my Linux system but it's obviously not battle-tested yet.
The most essential TODO comments ones are for uploading Debian packages.
Iteration on the script itself is usually quite fast. I run something like
As a temporary hack, the Debian packages are currently built in a Docker container.
It'd be easy to skip Docker when debmake is installed on the host system.
We don't yet pass through gpg-agent into Docker, so the debuild process requires interactive password input.
It takes a really long time (> 15 minutes) to build all Debian packages because we rebuild them sequentially for all Ubuntu releases (mantic, jammy, focal, bionic and xenial) even though only "debian/changelog" is different.
For iterating on the script, we can use "--no-rebuild-debs" to reuse the the packages after they've been built once.
Of course this is only valid if the tarball has not changed since.
We could probably ask debuild to validate this, or speed up the process in a different way, at least parallelize.
Future ideas:
talk to the github API, the script already has enough information).