Open Stack

Hi,

> Wiadomość napisana przez Martin André <m.andre at redhat.com> w dniu 03.05.2018, o godz. 15:01:
> 
> On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott <j.harbott at x-ion.de> wrote:
>> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski <skaplons at redhat.com>:
>>> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

— 
Best regards
Slawek Kaplonski
skaplons at redhat.com