Excerpts from Doug Hellmann's message of 2017-10-24 09:42:25 -0400: > 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. > > 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? > > (b) Do we want to have multiple release job templates due to custom > dependencies (or any other reason)? > > Thoughts? > > Doug >
Based on the conversation in this thread and on IRC, we decided to keep the job variants and update the releases repo so projects can explicitly indicate that they are using those variants instead of the default. See https://review.openstack.org/515119 for that change, and there are related changes in the series for deliverable files that needed to be updated. 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
