On Wed, Feb 14, 2018 at 4:05 PM James E. Blair <cor...@inaugust.com> wrote:
> Andrea Frittoli <andrea.fritt...@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
> > 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.
That's what I was thinking about,
> 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
> 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.
I agree with your concerns, but the problem is that the current
renders job templates rather useless. Each project has to re-add each job
template in its pipeline content definition to be able to apply irrelevant
that will turn stale if a template is modified.
With the migration to zuulv3 native jobs there is a lot of job renaming and
removing jobs going on, so for instance if a job is removed what used to be
irrelevant files may become running an extra job.
I don't really have a solution for this, but perhaps someone has an idea?
Andrea Frittoli (andreaf)
OpenStack Development Mailing List (not for usage questions)