On Tue, Oct 24, 2017 at 09:42:25AM -0400, Doug Hellmann wrote: > The neutron queens milestone release is held up right now because > some of the repositories are using a release job template that isn't > recognized by the validation code in the releases repository. I'm > trying to decide between adding the custom job template to the > validation code or changing the release jobs for those neutron > repositories to use the one that isn't custom. I think we'll have > the same problem with horizon plugins using the custom job template > set up for them. > > It looks like the publish-to-pypi-neutron template modifies > publish-to-pypi by adding openstack/neutron to the required-repositories > list for the release-openstack-python job. That repository was also at > some point added directly to the release-openstack-python job. So > technically the extension via the template is not needed. The same > applies to publish-to-pypi-horizon. > > I see a few issues with keeping job template variants: > > 1. Having multiple release job variants complicates the release > repo validation logic. That logic was put in place after we > discovered several projects without release jobs defined at all, > so we definitely want to keep some level of validation in place. > > 2. As we continue to make changes to the release jobs, we're going > to have to consider whether to make those changes in multiple > places, which seems error prone.
This is my big concern. Chances are very likely things will get missed. > > 3. As we find other projects with more dependencies, we're going > to end up with more custom templates. > > Those issues may be mitigated if we move the release job definitions > into the releases repo as we have discussed, because it will be > more obvious that we have multiple related templates that are > variants of one another and we can make the relevant changes all > together in one patch. > > One alternative to keeping multiple variants, and defining more in > the future, is to add required-repositories to the release-openstack-python > job directly, as we discover they are needed. Of course that means > we will clone repositories for some jobs that don't actually use > them. I don't know how big of an issue that really is, but the issue > of not knowing which instances of a job actually need a particular > dependency seems like more of a justification for keeping separate > templates than any runtime savings we would have by skipping a > couple of extra calls to git clone. > > It feels like we have two related by not necessarily dependent > policy questions we need to answer before we decide how to proceed: > > (a) Do we want to move the release job definitions from project-config > and openstack-zuul-jobs to the releases repo? > This seems like a good compromise to me. If we at least have them all in one place, it will make it a lot easier to make sure we are able to get everything updated as needed. > (b) Do we want to have multiple release job templates due to custom > dependencies (or any other reason)? > I'm guessing we will want this. We will most likely at some point have some need to have unique requirements for certain jobs. > Thoughts? > > Doug > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev