Build failed. - publish-openstack-releasenotes-python3 http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : POST_FAILURE in 13m 53s - publish-openstack-releasenotes http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : SUCCESS in 13m 54s
zuul@openstack.org writes:
Build failed.
- publish-openstack-releasenotes-python3 http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : POST_FAILURE in 13m 53s - publish-openstack-releasenotes http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : SUCCESS in 13m 54s
_______________________________________________ Release-job-failures mailing list Release-job-failures@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
Doug Hellmann <doug@doughellmann.com> writes:
zuul@openstack.org writes:
Build failed.
- publish-openstack-releasenotes-python3 http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : POST_FAILURE in 13m 53s - publish-openstack-releasenotes http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/pu... : SUCCESS in 13m 54s
_______________________________________________ Release-job-failures mailing list Release-job-failures@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
participants (2)
-
Doug Hellmann
-
zuul＠openstack.org