Drop need to re-tag during release process
Tasks
-
Check if the MR should close #18472 (closed) as well -
Update #18472 (closed) that the first issue is solved
-
-
Update release process
Proposal
In release_process.mdwn
we have:
Tag the release in Git
======================
[...]
Known limitations:
- Pushing the tag is needed so that the APT repository is updated, and the Tails
APT configuration works at build and boot time. It might be premature, as
testing might reveal critical issues, but this is a signed tag, so it can be
overridden later.
- From this push of a tag, the release branch will fail to build because the
last changelog entry is unreleased but corresponds to an existing tag.
Don't worry about it, this will be fixed shortly.
Indeed, it would be nice to not have to re-tag. If one is unlucky and fetch while the first tag is available then a normal get fetch/pull
won't update the tag, so one must realize that a git fetch --tags --force
is needed (this actually happened to me this release). And on tails-dev@ I just saw:
to whoever caused the 6.1 retagging fuzz, I lost a full day of testing work because of that, I hate you. Kidding <3
groente is innocent! This is the fault of the release process!
I think it is possible to skip the re-tagging simply by reordering how we do stuff during the release. The observation I made to realize this is that "Prepare the versioned APT suites" can be done after the final tag, removing the need for a first tag.
We currently have the following sections (and subsections when relevant), in order:
- Build the almost-final images
- Tag the release in Git (first tag that will be overwritten)
- Prepare the versioned APT suites
- Build images
- Sanity check
- SquashFS file order
- Build the final images (when we do the final re-tagging)
- Verify that Jenkins reproduced your images
- Initialize the website release branch
I think we should do this (only sections with a parenthesis are moved/modified):
- Build the almost-final images
- SquashFS file order (I moved this one out of "Build images" below just to make that section more focused, and it fits pretty well directly after "Build the almost-final images", but it could remain as the step following "Sanity check")
- Build images
- Sanity check
- Finalize and tag the release (this is the "Build the final images" section, until pushing the tag)
- Prepare the versioned APT suites
- Build the final images (this section is now just
rake build
and the following steps, except we might rephrase things: it is more likely that the RM has to manually trigger a build on jenkins because the one started when pushing in "Tag the release in Git" will fail if preparing the versioned APT suite takes longer than jenkins building the wiki) - Verify that Jenkins reproduced your images
- Initialize the website release branch
As a diff, if it helps:
* Build the almost-final images
-* Tag the release in Git (first tag that will be overwritten)
-* Prepare the versioned APT suites
+* SquashFS file order (I moved this one out of "Build images" below just to make that section more focused, and it fits pretty well directly after "Build the almost-final images", but it could remain as the step following "Sanity check")
* Build images
- Sanity check
- - SquashFS file order
- - Build the final images (when we do the final re-tagging)
+ - Finalize and tag the release (this is the "Build the final images" section, until pushing the tag)
+ - Prepare the versioned APT suites
+ - Build the final images (this section is now just `rake build` and the following steps, except we might rephrase things: it is more likely that the RM has to manually trigger a build on jenkins because the one started when pushing in "Tag the release in Git" will fail if preparing the versioned APT suite takes longer than jenkins building the wiki)
- Verify that Jenkins reproduced your images
- Initialize the website release branch
This results in the following changes:
- We only tag once, yay!
- The build is not broken for 15+20 minutes between the (old) "Tag the relese in Git" until re-pushing the tag in the (old) "Build the final images"
- Instead the build is broken for 15 minutes between the (new) "Tag the release in Git" and finishing the (new) "Prepare the versioned APT suites"
- The probability that the RM must manually start the final build on jenkins is slightly increased, which isn't so bad IMHO
This looks like a cheap, net improvement to me.