Open Stack

On Wed, Feb 14, 2018 at 4:05 PM James E. Blair <corvus at inaugust.com> wrote:

> 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.


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
> 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.
>

I agree with your concerns, but the problem is that the current
implementation
renders job templates rather useless. Each project has to re-add each job
in a
template in its pipeline content definition to be able to apply irrelevant
files, and
that will turn stale if a template is modified.

With the migration to zuulv3 native jobs there is a lot of job renaming and
adding/
removing jobs going on, so for instance if a job is removed what used to be
a setting
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)


> -Jim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180214/35de99eb/attachment.html>