[release] Independent release jobs are still using old release job templates

Stephen Finucane stephenfin at redhat.com
Fri Mar 11 12:26:38 UTC 2022

tl;dr: How do we get projects using the independent release process to use the
openstack-python3 zuul job template corresponding to the latest release? I've
noticed a couple of patches like [1] popping up for oslo-affiliated projects.
These projects are currently using the python3 zuul job templates corresponding
to an older release (e.g. Wallaby) and the author is correctly updating them to
use the most recent release. These initially caught me off-guard since I'm used
to seeing a bot propose these changes but I've realized that all affected
projects are using the "independent" release process and therefore don't receive
a new stable branch nor related bot-proposed commits. This leaves us in a bit of
a pickle though. There are a lot of projects using this release process, and
there's effectively zero chance that someone is going to remember to bump the
jobs every single release.

While some could argue that this is "working as designed", it seems important to
me that we would be testing these projects against the supported runtimes for
the release currently under development. As such, how should we try to address
this? One option I see is to add a new generic 'openstack-python3-jobs' template
which would always duplicate the jobs used for the current release. I've
proposed that here [2]. There are some pros and cons to this approach:

 * PRO: Minimal effort from everyone.
 * CON: The HEAD of master for each project could be broken and we'd never know
   until some change was proposed to master (note: this is effectively the
   status quo right now, so it's not a big break)
 * CON: If those independent projects had an alternative to stable branches
   (i.e. semver branches), those would eventually break as the runtimes kept

The other option is to extend the openstack bot to propose release bump patches
against these independent projects. This has the inverse pro/con balance:

 * PRO: We get a regular "check-up" on the health of the project whenever these
   patches are proposed.
 * PRO: Long-lived stable branches should stay working
 * CON: Lots of busy work for reviewers.

What are everyone's thoughts? I'm in favour of the first approach (generic
'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
go with the first approach, we'd probably want to script something to "fix" all
the existing independent projects rather than attempt to find and fix them


PS: Apologies if this has been discussed previously. I clearly missed that

[1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
[2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286

More information about the openstack-discuss mailing list