Doug Hellmann <d...@doughellmann.com> writes: > z...@openstack.org writes: > >> Build failed. >> >> - publish-openstack-releasenotes-python3 >> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/ >> : POST_FAILURE in 13m 53s >> - publish-openstack-releasenotes >> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/ >> : SUCCESS in 13m 54s >> >> _______________________________________________ >> Release-job-failures mailing list >> release-job-failu...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > > Keystone is configured in stable/queens with the release-notes-jobs > project template and in master with the release-notes-jobs-python3 > template. This is, AFAICT, exactly what we said should be done. However, > both of the templates include jobs in the "tag" pipeline, and tags are > not branch-aware. That means we end up running both versions of the > release notes publishing jobs when we tag a release, and the results may > be unpredictable. This problem will affect other projects as well. > > I think we have a few options. > > 1. Move the job settings out of the source repository into > project-config, like we do for the release jobs, so that we always > run the same version in all cases. > > This has two downsides. > > First, we would have to support the python3 variant even on very old > stable branches. That shouldn't be a very big concern, though, > because that job does not install the source for the project or its > dependencies. > > Second, we would have to modify all of the zuul configurations for > all of our old branches, again. As much as I'm enjoying the jokes > about how I'm padding my contribution stats this cycle, I don't > really want to do that. > > 2. Make the job itself smart enough to figure out whether to run with > python 2 or 3. > > We could update both jobs to look at some setting in the repo to > decide which version to use. This feels excessively complicated, > might still result in having to modify some settings in the stable > branches, and would mean we would have to customize the shared > versions of the jobs defined in the zuul-jobs repo. > > 3. Modify the python 2 version of the project template > ("release-notes-jobs") to remove the "tag" pipeline settings. > > This would let us continue to use the python 2 variant for tests and > when patches merge, and only use the python 3 job for tags. As with > option 1, we would have to be sure that the release notes job works > under python 3 for all repos, but as described above that isn't a big > concern. > > I think we should take option 3, and will be preparing a patch to do > that shortly. > > Did I miss any options or issues with this approach? > > Doug
See https://review.openstack.org/614758 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