<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 1, 2018 at 1:58 AM, James E. Blair <span dir="ltr"><<a href="mailto:corvus@inaugust.com" target="_blank">corvus@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
If you've had difficulty overriding jobs in project-templates, please<br>
read and provide feedback on this proposed change.<br>
<br>
We tried to make the Zuul v3 configuration language as intuitive as<br>
possible, and incorporated a lot that we learned from our years running<br>
Zuul v2. One thing that we didn't anticipate was how folks would end up<br>
wanting to use a job in both project-templates *and* local project<br>
stanzas.<br>
<br>
Essentially, we had assumed that if you wanted to control how a job was<br>
run, you would add it to a project stanza directly rather that use a<br>
project-template. It's easy to do so if you use one or the other.<br>
However, it turns out there are lots of good reasons to use both. For<br>
example, in a project-template we may want to establish a recommended<br>
way to run a job, or that a job should always be run with a set of<br>
related jobs. Yet a project may still want to indicate that job should<br>
only run on certain changes in that specific repo.<br>
<br>
To be very specific -- a very commonly expressed frustration is that a<br>
project can't specify a "files" or "irrelevant-files" matcher to<br>
override a job that appears in a project-template.<br>
<br>
Reconciling those is difficult, largely because once Zuul decides to run<br>
a job (for example, by a declaration in a project-template) it is<br>
impossible to dissuade it from running that job by adding any extra<br>
configuration to a project. We need to tread carefully when fixing<br>
this, because quite a number of related concepts could be affected. For<br>
instance, we need to preserve branch independence (a change to stop<br>
running a job in one branch shouldn't affect others). And we need to<br>
preserve the ability for job variants to layer on to each other (a<br>
project-local variant should still be able to alter a variant in a<br>
project-template).<br>
<br>
I propose that we remedy this by making a small change to how Zuul<br>
determines that a job should run:<br>
<br>
When a job appears multiple times on a project (for instance if it<br>
appears in a project-template and also on the project itself), all of<br>
the project-local variants which match the item's branch must also match<br>
the item in order for the job to run. In other words, if a job appears<br>
in a project-template used by a project and on the project, then both<br>
must match.<br></blockquote><div><br></div><div>I might be misunderstanding at which point a job is chosen to be ran and therefore when it's too late to dissuade it. However, if possible, would it make more sense for the project-local copy of a job to overwrite the supplied files and irrelevant-files? This would allow a project to run a job when it otherwise doesn't match.<br><br></div><div>What happens when something is in both files and irrelevant-files? If the project-template is trying to say A is in 'files', but the project-local says A is in 'irrelevant-files', should that overwrite it?<br><br></div><div>Cheers,<br></div><div>Josh<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This effectively causes the "files" and "irrelevant-files" attributes on<br>
all of the project-local job definitions matching a given branch to be<br>
combined. The combination of multiple files matchers behaves as a<br>
union, and irrelevant-files matchers as an intersection.<br>
<br>
================ ======== ======= =======<br>
Matcher Template Project Result<br>
================ ======== ======= =======<br>
files AB BC ABC<br>
irrelevant-files AB BC B<br>
================ ======== ======= =======<br>
<br>
I believe this will address the shortcoming identified above, but before<br>
we get too far in implementing it, I'd like to ask folks to take a<br>
moment and evaluate whether it will address the issues you've seen, or<br>
if you foresee any problems which I haven't anticipated.<br>
<br>
Thanks,<br>
<br>
Jim<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>