Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Release automation script #10449

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Release automation script #10449

wants to merge 2 commits into from
+407 −0

Commits on Apr 18, 2024

  1. Add sphinx-markdown-builder for generating release notes 

    Without this, Sphinx refuses to use the "-b markdown" builder (see next commit).
    @krobelus
    krobelus committed Apr 18, 2024
    Configuration menu
    Copy the full SHA
    aa26546 View commit details
    Browse the repository at this point in the history

  2. Release automation script 

    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
    @krobelus
    krobelus committed Apr 18, 2024
    Configuration menu
    Copy the full SHA
    e5e8670 View commit details
    Browse the repository at this point in the history