Open Stack

On 2013-10-01 09:21:23 +0200 (+0200), Åsmund Østvold wrote:
[...]
> What I do not understand is how the Jenkins compile jobs know
> what Gerrit changes should be included in the different
> concurrent regression runs.
[...]

It might not be spelled out explicitly in the documentation, but
Zuul determines what changes should be stacked for a particular
Jenkins job's workspace based on a number of factors and then
provides those as a separate git ref which can be checked out by the
Jenkins job getting triggered.

http://ci.openstack.org/zuul/triggers.html#zuul-references

First, if there are dependent changes from Gerrit's perspective,
these are treated as a unit and are checked out together. If the job
is triggered in an independent pipeline then the change is tested as
merged to the current target branch tip. If in a dependent pipeline
instead, the change is tested as merged to the other changes ahead
of it in the queue which are still in the process of being tested
and have not yet reported the completion status for all their jobs
(or to the target branch tip if there are no other changes ahead of
it for the same project and branch).

The above is a somewhat naive description--Zuul also recalculates
the git graph and builds new refs for changes on the fly as those
ahead of them fail jobs, since tests run against a speculative
branch state containing changes which will not be included once the
change in question is finally merged to target branch for a project
are not valid and will need to be restarted with those other changes
omitted. Much of this behavior depends on configuration and the
specifics of your deployment, however, and so may not be applicable
to your particular use case.
-- 
Jeremy Stanley