On 17/02/26 23:34, Jeremy Stanley wrote:
In your Step 2 simple change "Automation […] builds test versions of
release artifacts and exercises them" to "Automation […] commits test
versions of the release artifacts, exercises them creates a release
artefact by `git-archive`-ing that commit", and in Step 4 have the
automation push two tags (v1.2.3 and v1.2.3-release) instead of just one.
I think you're suggesting v1.2.3 would be the "clean" tag at the point
on the original branch from which an ephemeral release branch is
created, and then v1.2.3-release would be a "dirty" tag on the ephemeral
release branch at the point after a commit containing generated files is
merged?
This generated commit would still need to go through human review and
approval before merging to the ephemeral branch, and then once merged
the new v1.2.3-release tag request (auto-)proposed for review, reviewed
and approved. I don't see a way to remove these checkpoints without
allowing automation to merge unreviewed commits and push unreviewed tags.
I don't think merges are necessary. And the tags should be pushed only
after they are reviewed, just like tarballs are published only after
reviewing them. (I assume the tarballs are generated locally? and
reviewed _before_ being published.)
Maybe the compromise you're hinting at is that because the generated
files which get added/changed in release tarballs aren't being directly
reviewed, and the orphaned v1.2.3-release tag is merely a representation
of the corresponding tarball's contents within a Git working tree, any
difference between the working tree at v1.2.3 and v1.2.3-release
shouldn't need to be reviewed either?
This is more in line with what I was thinking.
Here is a step-by-step illustration of what I imagine the process could
look like, illustrated with git --graph.
We start from a random point in time.
* 3eff283 (HEAD -> master) add color widget
* ce6ae4d revert hack
* fbc0a11 add docs
* 7f558c8 fix rendering
* 4960f2b new feature
The release manager says "ce6ae4d is a good candidate for v1.2", so it
does all the testing that must be done and then tags it. (No changes
from the current workflow.)
In the meantime other people have committed to the master branch.
* 3573730 (HEAD -> master) add configuration option
* 3eff283 add color widget
* ce6ae4d (tag: v1.2) revert hack
* fbc0a11 add docs
* 7f558c8 fix rendering
* 4960f2b new feature
Now the extra files (AUTHORS, etc) get generated by a script. The
release manager (+ others) reviews and tests them. BUT, INSTEAD of
putting them in a tarball, they are put in a new commit whose parent is
v1.2 and this commit is tagged v1.2-release (technically, this can be
done atomically and without a new branch, if your infra is able to
manipulate Git objects directly).
* 3573730 (HEAD -> master) add configuration option
* 3eff283 add color widget
| * 701e9ab (tag: v1.2-release) Release version 1.2
|/
* ce6ae4d (tag: v1.2) revert hack
* fbc0a11 add docs
* 7f558c8 fix rendering
* 4960f2b new feature
(Obviously all these tags are signed, just like you do now.)
The tarball, if still needed, can be created by git-archive'ing the tag
v1.2-release.
These release tags are not merged back into the main history.
Nevertheless they may be the tag on top of which the Debian branches are
created and merged.
After another release the repo history will look like this:
* f95ffb1 (HEAD -> master) update homepage
* 229d4dd remove old code
| * 8d9f2fc (tag: v1.3-release) Release version 1.3
|/
* dadc8e7 (tag: v1.3) improve wording
* 2bc4d91 fix date
* 3573730 add configuration option
* 3eff283 add color widget
| * 701e9ab (tag: v1.2-release) Release version 1.2
|/
* ce6ae4d (tag: v1.2) revert hack
* fbc0a11 add docs
* 7f558c8 fix rendering
* 4960f2b new feature
I do not see in this workflow any additional manual steps compared to
what you already have. And it has the advantage of keeping Git as the
main source of truth (the tarball being just a materialization of a
single tag without its history). The disadvantage would be that the
infra that does the release must be changed to produce the extra tag
instead of tarball. But that is a one-time cost, not a recurring one.
Regards,
--
Gioele Barabucci
