This would 'just' mean adding %vote=Code-Review+2 to the git ref, I think. A quick patch in the branch.py code to add a new flag (default False) and then a fiddle on the jenkins job.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
make-release: Add `--push-option` to branch.py | mediawiki/tools/release | master | +13 -4 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | dancy | T196515 Automate the Train | |||
Resolved | • dduvall | T278993 Automate the merge of the weekly branch cut |
Event Timeline
May be controversial, added to discussion at next Release-Engineering-Team team meeting
If we're auto +2'ing, does the branch cut change still need to go through review? I ask because branch.py already has a --no-review option which could skip that process entirely.
It's possible that the branch would fail CI for some reason; I think we'd want to know that ahead of time, rather than when we make the first back-port. --no-review bypasses CI and just force-pushes, I think?
That makes sense. (And yes, --no-review pushes directly to the branch instead of refs/for/{branch}.)
Change 677324 had a related patch set uploaded (by Dduvall; author: Dduvall):
[mediawiki/tools/release@master] make-release: Add `--push-option` to branch.py
Change 677324 merged by jenkins-bot:
[mediawiki/tools/release@master] make-release: Add `--push-option` to branch.py