Open Stack

On 2017-10-25 00:51, James E. Blair wrote:
> 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.


I'm fine with this and suggest to update the infra manual with the
policy. Also, the explanation about job variants should be in the infra
manual,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
       HRB 21284 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126