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