Release day
You want the merge requests targeting one release branch split by what you can do with them: the ones that can go now, the ones still in the way, and the ones that already landed. Build the three tabs on the morning of the release, and change the branch name for the next one.
Steps
| Step | Key | What it does |
|---|---|---|
| 1 | b then Enter on platform | The whole group tree |
| 2 | f then target:release/2.4 draft:false approved:true conflicts:false | What can go now |
| 3 | P, named 2.4 ready | Tab one |
| 4 | f, change to approved:false, add sort:updated-asc | What is in the way, oldest first |
| 5 | P, named 2.4 blocked | Tab two |
| 6 | f then state:merged merged > 14d | What already landed |
| 7 | P, named 2.4 merged | Tab three |
Next release, press f on each tab and change the branch. Three edits, and you see each result before you keep it.
What each tab answers
Ready is the merge list. approved:true with conflicts:false means every row is one you can act on now, and the diff column gives the size of each one before you open it.
Blocked is the chase list, oldest first. The blockers column names who to chase and for what: needs 1 is a reviewer, conflicts is the author, 3 threads open is a conversation.
Merged is the release note. Two weeks of what landed on the branch, on a slow refresh interval because it does not change quickly.
Row actions
| Key | Action | Key | Action |
|---|---|---|---|
| m | merge, with the squash and branch deletion named in the prompt | Y | copy the URL, to paste into the release thread |
| v | approve | Space | multi-select, then act on all of them |
The prompt says so: "Add !2914 to the merge train for release/2.4? It will merge after 2 MRs ahead of it." The wording changes because the outcome changes. See merge trains.
Variations
One tab instead of three
Drop the approval filters and keep target:release/2.4 draft:false sort:updated-asc. Every row then carries its own answer in the blockers column: ready can go now, needs 1 is waiting on a reviewer, conflicts is waiting on the author. One tab, read top to bottom.
Three tabs are better on a release with more than about twenty merge requests, because ready stops being a thing you scan for and becomes a thing you work through.
Cherry-pick candidates still on main
Filter to state:merged target:main merged > 7d label:release-candidate and pin it. These are the ones somebody asks about at 4pm.