On Thu, Feb 15, 2018 at 1:43 AM, Andrea Frittoli <andrea.fritt...@gmail.com> wrote: > > > 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?
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 [1] ? i mean no 'integrate-gate' etc template. ..1 https://docs.openstack.org/infra/manual/zuulv3.html#what-to-convert -gmann > > 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 > __________________________________________________________________________ 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
