On 2021-02-09 19:03:58 +0200 (+0200), Marios Andreou wrote: [...]
just to be clear however, note that this means that there will be no stable/wallaby version of these upgrades jobs, or at least it will be a lot harder to add them if we aren't running these jobs against master. In the 'normal' case, the non-voting master jobs become the voting stable/latest once we have created the new latest branch. If we remove master we may have a challenge to add voting stable/wallaby versions when the time comes.
Based on our recent discussions, we don't *want* stable/wallaby versions since we want to eventually remove all the upstream upgrade jobs once d/stream replacements have been put in place.
The point then is that ideally we need to be in a position to do that (i.e. replacement jobs in place) before stable/wallaby is branched, otherwise we may have a tough time adding stable/wallaby versions of the (removed) master upgrade jobs.
If for some reason you aren't able to get that far in Wallaby, running this once a day in the periodic pipeline in OpenDev's Zuul would still be *far* less resource-intensive than the current state of running multiple times for most proposed changes, and so could serve as a reasonable compromise. -- Jeremy Stanley