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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
