[tripleo][ci] socializing upstream job removal ( master upgrade, scenario010 )
marios at redhat.com
Wed Feb 10 06:39:42 UTC 2021
On Tue, Feb 9, 2021 at 7:19 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
> 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
> > 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
> > 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
> > replacement jobs in place) before stable/wallaby is branched, otherwise
> > 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.
ack thanks and yeah we are definitely keeping our 3rd party periodics on
these but good point we could also consider the upstream periodic i almost
forgot we have one of those defined too ;)
> Jeremy Stanley
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss