Would be rather useful to be able to reattempt gate-and-submit with 'recheck'. Gotta add to the gate-and-submit pipeline a new condition for comment-added matching 'recheck' and the change having CR+2, and another condition to prevent that in the test (i.e. CR is not +2).
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Declined | None | T105474 'recheck' on a CR+2 patch should trigger gate-and-submit, not test | |||
Resolved | jbond | T222689 Upload zuul_2.5.1-wmf9 to apt.wikimedia.org |
Event Timeline
I looked a bit at it, when a recheck comment is added on a change having CR+2:
- gate-and-pipeline should react to it, but only if there is CR+2 approval
- test should not enqueue it, i.e. ignore changes that have a Code-Review: +2
Change 227223 had a related patch set uploaded (by Hashar):
'recheck' on CR 2 now triggers gate-and-submit
Change 368154 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] 'recheck' on CR 2 now triggers gate-and-submit
Change 227223 abandoned by Hashar:
'recheck gate' on CR 2 now triggers gate-and-submit
Reason:
There are too many patchsets spam on this change. I have sent the original patchset as a new change: https://gerrit.wikimedia.org/r/368154
Seems that feature is now working. Potentially because when commenting recheck the event emitted by Gerrit now carries the Code-Review:+2 vote and hence the event is matched by the gate-and-submit pipeline.
However, it also enters the test pipeline. So most probably we would want test to filter out +2ed changes?
Change 368154 merged by jenkins-bot:
[integration/config@master] zuul: skip test/test-prio for CR+2 changes
Change 508323 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] Revert "zuul: skip test/test-prio for CR+2 changes"
Change 508323 merged by jenkins-bot:
[integration/config@master] Revert "zuul: skip test/test-prio for CR+2 changes"
Eventually my change broke Zuul workflow entirely. Various changes could not enter the test pipelines. The patch added:
reject: # Patches handled by gate pipelines - T105474 approval: - code-review: 2
An example with https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/508011/10 which has been send at 13:26 UTC. In Zuul:
2019-05-06 13:26:35,417 INFO zuul.Scheduler: Adding operations/puppet, <Change 0x7f81228b5f10 508011,10> to <Pipeline test-prio> 2019-05-06 13:26:35,417 DEBUG zuul.IndependentPipelineManager: Considering adding change <Change 0x7f81228b5f10 508011,10> Change <Change 0x7f81228b5f10 508011,10> does not match pipeline requirement <ChangeishFilter reject_approvals: [{'code-review': 2}]>
I need a test that is the other way around, namely ensure a patch without approval is accepted :D
And I would guess patch Zuul with Upstream patch https://review.opendev.org/#/c/589762/
Markus Hosch @ bmw.de
Fix reject clauses in the absence of approvals This change fixes a behavior that might be surprising to a user: If a reject clause is configured for a pipeline, the reject clause is always true even if no approval is set. If, however, an unrelated approval is added to the change, the reject clause is evaluated as expected. The root cause was a check that assumed that the absence of approvals will lead to a negative filter result. However, this is only true for requirements.
Change 508509 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/zuul@patch-queue/debian/jessie-wikimedia] WMF: backport Fix reject clauses in the abscence of approvals
Change 508511 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/zuul@debian/jessie-wikimedia] patch: Fix reject clauses in the absence of approvals
Change 508512 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] zuul: skip test/test-prio for CR+2 changes
Change 508509 merged by Hashar:
[integration/zuul@patch-queue/debian/jessie-wikimedia] WMF: backport Fix reject clauses in the abscence of approvals
I have backported the upstream patch https://review.opendev.org/#/c/589762/ which fix rejection always being true when a change lacks approvals. That is now covered by a test in integration/config ( https://gerrit.wikimedia.org/r/#/c/integration/config/+/508512/3/tests/test_zuul_scheduler.py ) which is roughly:
change_without_approvals = zuul.model.Change( self.sched.getProject('mediawiki/core')) change_without_approvals.branch = 'master' self.assertTrue( pipeline.manager.addChange(change_without_approvals), "Independent pipeline '%s' must accept a change " "without any approval" % (p.name) )
Change 508511 merged by jenkins-bot:
[integration/zuul@debian/jessie-wikimedia] patch: Fix reject clauses in the absence of approvals
Change 508520 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/zuul@debian/jessie-wikimedia] 2.5.1-wmf8: bugs fix following incident
Change 508520 merged by jenkins-bot:
[integration/zuul@debian/jessie-wikimedia] 2.5.1-wmf8: bugs fix following incident
Mentioned in SAL (#wikimedia-releng) [2019-05-07T10:57:47Z] <hashar> Upgraded Zuul to 2.5.1-wmf8 # T105474 T140297
Mentioned in SAL (#wikimedia-operations) [2019-05-07T11:16:22Z] <hashar> Downgraded Zuul back to 2.5.1-wmf7 # T105474 T140297
Mentioned in SAL (#wikimedia-operations) [2019-05-13T09:33:27Z] <hashar> Upgrading Zuul 2.5.1-wmf7 -> 2.5.1-wmf9 T105474
Change 508512 merged by jenkins-bot:
[integration/config@master] zuul: skip test/test-prio for CR+2 changes
Mentioned in SAL (#wikimedia-releng) [2019-05-13T10:37:26Z] <hashar> Rolling CI config change https://gerrit.wikimedia.org/r/508512 which caused some patches to not be processed last week # https://wikitech.wikimedia.org/wiki/Incident_documentation/20190506-zuul / T105474
So now it should be fixed. The second iteration of the config change ( https://gerrit.wikimedia.org/r/508512 ) does have a test that failed before Zuul 2.5.1wmf8 but now pass.
Change 510148 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] Revert "zuul: skip test/test-prio for CR+2 changes"
Change 510148 merged by jenkins-bot:
[integration/config@master] Revert "zuul: skip test/test-prio for CR+2 changes"
The patch worked but it had a few culprit as described in T223212 and T223209 which would need to be addressed:
- operations/puppet does not have a gate-and-submit so patches never get rechecked
- On a patch having code-review +2, if someone else comment recheck the comment message does not carry a CR+2 vote. gate-and-submit only process comments that have a code-review +2.
So it is a bit more complicated than expected. I have reverted the configuration change and do not plan to work on this any further (for now).
Declining to reflect the reality. I gave it a try and that failed for a bunch of reasons. The workaround is one has to issue a comment with a CR+2 and that triggers gate-and-submit.