Any patches to wmf/branch_cut_pretest are immediately +2'd so running the test pipeline is unncesssary and wasteful.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| zuul: do not test patches having CR+2 | integration/config | master | +6 -0 |
Event Timeline
Comment Actions
Thinking this through, we'd want to adjust the test-wmf trigger to ignore patchset-created events if the branch is branch_cut_pretest?
Comment Actions
I think that can be done by adding a reject-approval to the event. We did something like that on https://gerrit.wikimedia.org/r/c/integration/config/+/793458 which only applies to Code-Review +1 being cast by an approved user. scap-backport is in a similar situation.
Comment Actions
Change 999500 had a related patch set uploaded (by Hashar; author: Hashar):
[integration/config@master] zuul: do not test patches having CR+2
Comment Actions
Change 999500 merged by jenkins-bot:
[integration/config@master] zuul: do not test patches having CR+2
Comment Actions
Mentioned in SAL (#wikimedia-releng) [2024-02-09T15:05:04Z] <James_F> Zuul: Do not test patches having CR+2 for T357080
Comment Actions
OK, this seems to have worked e.g. on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SiteSettings/+/999891 from LibUp only went into gate-and-submit and never had the test pipeline run, which in general will save quite a lot of CI time. :-)
Nice idea, @taavi.
Comment Actions
I'm fairly sure LibUp patches have been configured that way for a while, LibUp will add V+1 to manually trigger test jobs when not +2'ing. But we'll see what happens with the next branch_cut_pretest job when it runs.