<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 1, 2018 at 10:02 AM, James E. Blair <span dir="ltr"><<a href="mailto:corvus@inaugust.com" target="_blank">corvus@inaugust.com</a>></span> wrote:</div><div class="gmail_quote">[...]<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay, let's summarize:<br>
<br>
Proposal 1: All project-template and project-local job variants matching<br>
the item's branch must also match the item.<br>
<br>
* Files and irrelevant-files on project-template and project stanzas are<br>
  essentially combined in a set intersection.<br>
* It's possible to further reduce the scope of jobs, but not expand.<br>
* Files and irrelevant-files are still independent matchers, and if both<br>
  are present, both must match.<br>
* It's not possible to alter a job attribute by adding a project-local<br>
  variant with only a files matcher (it would cause the whole job to run<br>
  or not run).  But it's still possible to do that in the main job<br>
  definition itself.<br>
<br>
Proposal 2: Files and irrelevant-files are treated as overwriteable<br>
attributes and evaluated after branch-matching variants are combined.<br>
<br>
* Files and irrelevant-files are overwritten, so the last value<br>
  encountered when combining all the matching variants (looking only at<br>
  branches) wins.<br>
* Files and irrelevant-files will be treated as a pair, so that if<br>
  "irrelevant-files" appears, it will erase a previous "files"<br>
  attribute.<br>
* It's possible to both reduce and expand the scope of jobs, but the<br>
  user may need to manually copy values from a parent or other variant<br>
  in order to do so.<br>
* It will no longer be possible to alter a job attribute by adding a<br>
  variant with only a files matcher -- in all cases files and<br>
  irrelevant-files are used solely to determine whether the job is run,<br>
  not to determine whether to apply a variant.<br>
<br>
I think both would be good solutions to the problem.  The key points for<br>
me are whether we want to keep the "alter a job attribute with variant<br>
with a files matcher" functionality (the "rebuild_index" example from<br>
above), and whether the additional control of overwriting the matchers<br>
(at the cost of redundancy in configuration) is preferable to combining<br>
the matchers.<br></blockquote><div><br></div><div>In the case of TripleO, I think proposal 2 is what we want.</div><div>We have stanzas defined in the templates definitions in openstack-infra/tripleo-ci repo, but really want to override the file rules per repo (openstack/tripleo-quickstart for example) and I don't think we want to have them both matching but so the last value encountered would win.</div><div>I'll let TripleO CI squad to give more thoughts though.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>
</div></div>