Hi, > Wiadomość napisana przez Martin André <[email protected]> w dniu 03.05.2018, > o godz. 15:01: > > On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott <[email protected]> wrote: >> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski <[email protected]>: >>> Hi, >>> >>> I wonder if there is any way to recheck only one type of job instead of >>> rechecking everything. >>> For example sometimes I have to debug some random failure in specific job >>> type, like „neutron-fullstack” and I want to collect some additional data >>> or test something. So in such case I push some „Do not merge” patch and >>> waits for job result - but I really don’t care about e.g. pep8 or UT >>> results so would be good is I could run (recheck) only job which I want. >>> That could safe some resources for other jobs and speed up my tests a >>> little as I could be able to recheck only my job faster :) >>> >>> Is there any way that I can do it with gerrit and zuul currently? Or maybe >>> it could be consider as a new feature to add? What do You think about it? >> >> This is intentionally not implemented as it could be used to trick >> patches leading to unstable behaviour into passing too easily, hiding >> possible issues. > > Perhaps for these type of patches aimed at gathering data in CI, we > could make it easier for developers to selectively trigger jobs while > still retaining the "all voting jobs must pass in the same run" policy > in place. > > I'm thinking maybe a specially formatted line in the commit message > could do the trick: > > Trigger-Job: neutron-fullstack
Yes, IMO it would be great to have something like that available :) > > Even better if we can automatically put a Workflow -1 on the patches > that contains a job triggering marker to prevent them from > accidentally merging, and indicate to reviewers they can skip these > patches. > It's not uncommon to see such DNM patches, so I imagine we can save > quite a lot of CI resource by implementing a system like that. And > devs will be happier too because it can also be tricky at times to > find what triggers a given job. That was my initial though when I wrote email about it :) Solution proposed by Jens is (almost) fine for me as it allows me to skip many tests but there is bunch of jobs defined in zuul directly (like openstack-tox-py27 or tempest-full) which are still running for my DNM patch. > > Martin > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev — Best regards Slawek Kaplonski [email protected] __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
