[openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
Doug Hellmann
doug at doughellmann.com
Thu Nov 1 12:52:05 UTC 2018
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
> 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
More information about the OpenStack-dev
mailing list