Command to create a release.
make request-release <sha>
make request-release # default to current trunk
This creates and pushes a new tag in the form
request/release/2020.02.20-01
.
A workflow picks up the tag and produces an issue.
The issue contains a link to a diff to the previously deployed release.
The issue description is expected to be updated to contain the release description, with a list of all changes. The full description of the issue will be "burnt-in" as the release description later on.
...
Having pondered, I'm coming to the conclusion that it's unnecessary to have an explicit release request command (except, it's probably good for creating fix-releases). We could just have a trigger on trunk receiving new commits and update a "long-running" release issue, or a create a new one if it doesn't exist already. This task would also update the name of the release to the current date automatically.
This means there will always be an open release issue when there are unreleased commits on trunk.
That would also mean we wouldn't need special release-request-tags.
Releases are approved by reviewers posting a comment in the form /approve <commit sha>
on the release issue. The release creation flow listens for comments on the issue and counts
the number of comments containing the /approve <sha>
with the sha the release tag is pointing
to.
Reviewers can withdraw their approval by removing their approving comment. (easier than introducing a disapprove-command and having to parse across messages).
The reviewers that approved the release will be "burnt-in" in the release description later on in the flow.
The release issue description can contain a helptext with available commands. If we put it after
a "tagging" html comment, that can be used to strip it from the resulting description burnt-in on
the release (eg description.split("<!--marker:ignore-below-->")[0]
):
- Update email copy
<!--marker:ignore-below-->
<!-- Text below will not appear on the release -->
Commands:
- `/approve <sha>`
- `/deploy`
When the release has been validated and has received the required number of approvals, the /deploy
command
can be issued. The command validates that all required checks have passed and that the required number of
approvals have been received. It can also check that there aren't any hot-release-issues open and deny deploying
on that basis.
If all checks pass, a release is built and published and deployment workflows are triggered. A release tag is created and the release page receives a "burnt-in" description of the release from the issue together with annotations for "Approved by: x, y" and "Triggered by: z".