At the infra meeting today, we discussed how to handle job variants. I will try to summarize the discussion and extrapolate some things.
The Zuul v3 migration doc in the infra manual is very clear that some project-templates should only be added in project-config, rather than in-repo[1]. However, there are some edge cases worth considering: First: projects may want to alter the behavior of those jobs (e.g., to run unit tests on an older node type). In these cases projects should leave the template in project-config, and just alter the job by adding a project-pipeline variant in-repo. Theoretically, projects could use this to make their py27 jobs non-voting. That would be a TC policy violation, but this system is not designed to enforce that policy, only facilitate it. Second: projects may want to cause those jobs not to run in some circumstances. Zuul's configuration for job variants is additive. Any job variants which match a change will be cumulatively applied to the final job configuration before it runs. However, once any job or variant for a project-pipeline matches a change, that job will run. There is not a way to have one variant match a change, and then have a second also match it and somehow cause the job not to run. Variants which don't match the job simply don't add their own attributes to it. This means that if a project wants to alter the files or irrelevant files list for a job covered by one of those templates, or avoid running a job on a particular branch, there is no way to do that if the template is applied in project-config. In these cases, I think the following policy should apply: 1) If you can use the project-template as-is, then it should be applied to the project in project-config. 2) If you want to improve the files or irrelevant-files matchers on the template in such a way that they can apply safely to everyone using the template, please do so. 3) If your project needs a job variant that is incompatible with the template, then remove it from project-config and add the individual jobs to the project in-repo. The project is still responsible for adhering to the PTI. As you can see, these aren't hard and fast rules, this is more of an attempt to gain clarity and be able to make helpful and consistent suggestions to folks about how to configure jobs in certain ways. -Jim [1] https://docs.openstack.org/infra/manual/zuulv3.html#what-not-to-convert _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
