[Release-job-failures] [release][infra] Tag of openstack/keystone failed
doug at doughellmann.com
Thu Nov 1 12:52:54 UTC 2018
Doug Hellmann <doug at doughellmann.com> writes:
> zuul at 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-failures at lists.openstack.org
> 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
> 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
> 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?
More information about the Release-job-failures