Open Stack

Andrea Frittoli <andrea.frittoli at gmail.com> writes:

>> That has no irrelevant-files matches, and so matches everything.  If you
>> drop the use of that template, it will work as expected.  Or, if you can
>> say with some certainty that nova's irrelevant-files set is not
>> over-broad, you could move the irrelevant-files from nova's invocation
>> into the template, or even the job, and drop nova's individual
>> invocation.
>>
> I don't think projects in the integrated gate should remove themselves
> from the
> template, it really helps keeping consistency.
>
> The pattern I've seen is that most projects repeat the same list of
> irrelevant files
> over and over again in all of their integration tests, It would be handy in
> future to
> be able to set irrelevant-files on a template when it's consumed.
> So we could have shared irrelevant files defined in the template, and
> custom ones
> added by each project when consuming the template. I don't this is is
> possible today.
> Does it sound like a reasonable feature request?

A template may specify many jobs, so if we added something like that
feature, what would the project-pipeline template application's
irrelevant files apply to?  All of the jobs in the template?  We could
do that.  But it only takes one exception for this approach to fall
short, and while a lot of irrelevant-files stanzas for a project are
similar, I don't think having exceptions will be unusual.  The only way
to handle exceptions like that is to specify them with jobs, and we're
back in the same situation.

Also, combining irrelevant-files is very difficult to think about.
Because it's two inverse matches, combining them ends up being the
intersection, not the union.  So if we implemented this, I don't think
we should have any irrelevant-files in the template, only on template
application.

I still tend to think that irrelevant-files are almost invariably
project-specific, so we should avoid using them in templates and job
definitions (unless absolutely certain they are universally applicable),
and we should only define them in one place -- in the project-pipeline
definition for individual jobs.

-Jim