Open Stack

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