<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 14, 2018 at 4:05 PM James E. Blair <<a href="mailto:corvus@inaugust.com">corvus@inaugust.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.com</a>> writes:<br>
<br>
>> That has no irrelevant-files matches, and so matches everything.  If you<br>
>> drop the use of that template, it will work as expected.  Or, if you can<br>
>> say with some certainty that nova's irrelevant-files set is not<br>
>> over-broad, you could move the irrelevant-files from nova's invocation<br>
>> into the template, or even the job, and drop nova's individual<br>
>> invocation.<br>
>><br>
> I don't think projects in the integrated gate should remove themselves<br>
> from the<br>
> template, it really helps keeping consistency.<br>
><br>
> The pattern I've seen is that most projects repeat the same list of<br>
> irrelevant files<br>
> over and over again in all of their integration tests, It would be handy in<br>
> future to<br>
> be able to set irrelevant-files on a template when it's consumed.<br>
> So we could have shared irrelevant files defined in the template, and<br>
> custom ones<br>
> added by each project when consuming the template. I don't this is is<br>
> possible today.<br>
> Does it sound like a reasonable feature request?<br>
<br>
A template may specify many jobs, so if we added something like that<br>
feature, what would the project-pipeline template application's<br>
irrelevant files apply to?  All of the jobs in the template?  We could<br>
do that. </blockquote><div> </div><div>That's what I was thinking about,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But it only takes one exception for this approach to fall<br>
short, and while a lot of irrelevant-files stanzas for a project are<br>
similar, I don't think having exceptions will be unusual.  The only way<br>
to handle exceptions like that is to specify them with jobs, and we're<br>
back in the same situation.<br>
<br>
Also, combining irrelevant-files is very difficult to think about.<br>
Because it's two inverse matches, combining them ends up being the<br>
intersection, not the union.  So if we implemented this, I don't think<br>
we should have any irrelevant-files in the template, only on template<br>
application.<br>
<br>
I still tend to think that irrelevant-files are almost invariably<br>
project-specific, so we should avoid using them in templates and job<br>
definitions (unless absolutely certain they are universally applicable),<br>
and we should only define them in one place -- in the project-pipeline<br>
definition for individual jobs.<br></blockquote><div><br></div><div>I agree with your concerns, but the problem is that the current implementation</div><div>renders job templates rather useless. Each project has to re-add each job in a</div><div>template in its pipeline content definition to be able to apply irrelevant files, and</div><div>that will turn stale if a template is modified.</div><div><br></div><div>With the migration to zuulv3 native jobs there is a lot of job renaming and adding/</div><div>removing jobs going on, so for instance if a job is removed what used to be a setting</div><div>irrelevant files may become running an extra job. </div><div> </div><div>I don't really have a solution for this, but perhaps someone has an idea?</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Jim<br>
</blockquote></div></div>