<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 1, 2018 at 1:23 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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">[...]</div></div></div><div dir="ltr"><div class="gmail_extra"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div class="m_-1751474697849264563gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div></blockquote><div><br></div><div>I agree,</div><div>Proposal #2 makes the most sense to me and seems more straight forward in that you have the ability to override and that the project overriding would need to handle both files and irrelevant-files from scratch.</div><div><br></div><div>Nice write up</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="m_-1751474697849264563gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"></div></div>
</div></div>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>