Saturday 1am and I have crazy idea. Whenever someone propose a patch to a wmf branch, jobs from test are triggered then the CR+2 trigger the same set of test via gate-and-submit.
Most of the cherry-picks have already been tested in master so we have high confidence it is going to pass just fine and the jobs can be skipped to speed up the process. On CR+2 we would still run all the tests just to make sure ™.
That would cut the backport waiting time by half.
This would make jenkins happy, when not running so much things.
test and gate-and-submit normally run in parallel, you have not to wait for the first to start the second
(Same on master when rebase a patch set and CR+2, both jobs run in parallel, test finished first)
(Going through some old tasks in the backlog)
That would cut the backport waiting time by half.
As pointed out by @Umherirrender, this wouldn't actually save time. It would only save Nodepool resources. And it would do so at the cost of hiding a problem until the very last minute in case someone does create the backport earlier.
In my experience, most patches in SWAT are not created during SWAT, they're created prior and then listed at https://wikitech.wikimedia.org/wiki/Deployments. Typically between 1 and 12 hours before the actual SWAT window. That's plenty of time to get feedback if something does fail.
While saving Nodepool resources is good, I'd recommend instead to investigate cancelling the 'test' pipeline jobs for a changeset when gate-and-submit pipeline is triggered for the same job. That achieves the same semantic intent without sacrificing critical feedback when creating backports ahead of time.
I don't agree with this at all. If the only time youll get feedback from the change is when its cr+2'd then that will slow down the overall code reviewing process.
Thank you Timo for the feedback. I am declining this crazy idea of mine since patches are typically sent ahead of time.
Anything that needs critical revert/deployment is usually done directly on the deployment servers and deployed right away bypassing Gerrit/CI/review etc. We catch up later up by sending the patch to Gerrit/CR+2 and just letting CI merge the already deployed change.
Note: there is another task to dequeue a change from test when a change enters gate-and-submit (T78328), though if jobs got triggered the instances have already been consumed. So that has little benefit to save Nodepool instances though releasing them earlier is still a good thing
T307180: Drop Selenium tests from gate-and-submit-wmf is a somewhat opposite proposal (test can be slow, gate should be fast as it cannot be done in advance).