On Fri, Jan 26, 2018 at 2:05 PM Balázs Gibizer <balazs.gibizer at ericsson.com> wrote: > Hi, > > I'm getting more and more confused how the zuul job hierarchy works or is > supposed to work. > > First there was a bug in nova that some functional tests are not triggered > although the job (re-)definition in the nova part of the project-config > should not prevent it to run [1]. > > There we figured out that irrelevant-files parameter of the jobs are not > something that can be overriden during re-definition or through > parent-child relationship. The base job openstack-tox-functional has an > irrelevant-files attribute that lists '^doc/.*$' as a path to be ignored > [2]. In the other hand the nova part of the project-config tries to make > this ignore less broad by adding only '^doc/source/.*$' . This does not > work as we expected and the job did not run on changes that only affected > ./doc/notification_samples path. We are fixing it by defining our own > functional job in nova tree [4]. > > [1] https://bugs.launchpad.net/nova/+bug/1742962 > [2] > https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380 > [3] > https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509 > [4] https://review.openstack.org/#/c/533210/ > > Then I started looking into other jobs to see if we made similar mistakes. > I found two other examples in the nova related jobs where redefining the > irrelevant-files of a job caused problems. In these examples nova tried to > ignore more paths during the override than what was originally ignored in > the job definition but that did not work [5][6]. > > [5] https://bugs.launchpad.net/nova/+bug/1745405 (temptest-full) > [6] https://bugs.launchpad.net/nova/+bug/1745431 (neutron-grenade) > > So far the problem seemed to be consistent (i.e. override does not work). > But then I looked into neutron-grenade-multinode. That job is defined in > neutron tree (like neutron-grenade) > That is wrong and it should not have happened. Grenade jobs that are shared by all the repos in the integrated gate should live in repos owned by QA/infra - it was never the plan for them to end up in the neutron repo. We're working on making grenade and multinode zuulv3 native jobs. Grenade jobs will leave in the grenade repo, once they're ready we will remove the legacy one from neutron side and add the new ones defined in grenade. Changes will be done to the job template accordingly which means that for teams that are consuming those jobs via the template only there'll be no action. Andrea Frittoli (andreaf) > but nova also refers to it in nova section of the project-config with > different irrelevant-files than their original definition. So I assumed > that this will lead to similar problem than in case of neutron-grenade, but > it doesn't. > > The neutron-grenade-multinode original definition [1] does not try to > ignore the 'nova/tests' path but the nova side of the definition in the > project config does try to ignore that path [8]. Interestingly a patch in > nova that only changes under the path: nova/tests/ does not trigger the job > [9]. So in this case overriding the irrelevant-files of a job works. (It > seems that overriding neutron-tempest-linuxbridge irrelevant-files works > too). > > [7] > https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159 > [8] > https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530 > [9] https://review.openstack.org/#/c/537936/ > > I don't see what is the difference between neutron-grenade and > neutron-grenade-multinode jobs definitions from this perspective but it > seems that the irrelevent-files attribute behaves inconsistently in these > two jobs. Could you please help me undestand how irrelevant-files in > overriden jobs supposed to work? > > cheers, > gibi > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180214/3931145b/attachment.html>