Open Stack

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