On Thu, Feb 15, 2018 at 1:43 AM, Andrea Frittoli
> 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
>> > 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
>> 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 in
> 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
> 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?
I am in favor of idea of not defining the irrelevant_files in base job
definition or template and have them defined by project in
project-pipeline only. This solve most of the issue even that can ask
each project to define the common irrelevant_files.
With that, should we keep the Template limited to system one only
which are mentioned here  ? i mean no 'integrate-gate' etc
> Andrea Frittoli (andreaf)
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)