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 > 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 >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev