[openstack-dev] [project-config][infra] Advanced way to run specific jobs against code changes
dmakogon at mirantis.com
Thu Dec 11 13:46:47 UTC 2014
Good day Stackers.
I’d like to raise question about implementing custom pipelines for Zuul.
For those of you how’s pretty familiar with project-config and infra
itself it wouldn’t be a news that for now Zuul layout supports only few
pipelines types 
Most of OpenStack projects are maintaining more than one type of drivers
(for Nova - virt driver, Trove - datastore drivers,
Cinder - volume backends, etc.). And, as it can be seen, existing jenkins
check jobs are not wisely utilize infra resources.
This is a real problem, just remember end of every release - number of
check/recheck jobs is huge.
So, how can we utilize resources more wisely and run only needed check job?
Like we’ve been processing unstable new check jobs - putting them into
‘experimental’ pipeline. So why can’t we provide such ability for projects
to define their own pipelines?
For example, as code reviewer, i see that patch touches specific
functionality of Driver A and i know that project testing infrastructure
provides an ability
to examine specific workflow for Driver A. Then it seems to be more than
valid to post a comment on the review like “check driver-a”. As you can see
i want to ask gerrit to trig custom pipeline for given project. Let me
describe more concrete example from “real world”. In Trove we maintain 5
drivers for different datastores and it doesn’t look like a good thing to
run all check jobs against code that doesn’t actually touch any of existing
drivers (this is what we have right now 
Now here comes my proposal. I’d like to extend existing Zuul
pipeline to support any of needed check jobs (see example of Triple-O, 
But, as i can, see there are possible problems with such
approach, so i also have an alternative proposal to one above. The only
one way to deal with such
approach is to use REGEX ‘files’ for job definitions (example:
requirements check job 
In this case we’d still maintain only one pipeline ‘experimental’
for all second-priority jobs. To make small summary, two ways
Pipeline(s) per Project. Pros: reviewer can trig specific pipeline by
himself. Cons: spamming status/zuul.
REGEX files per additional jobs.
Sorry, but i’m not able to describe all Pros/Cons for each of proposals.
So, if you know them, please help me to figure out them.
All thoughts/suggestions are welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev