[QA] How Zuul gating works (on +2)

[Antoine Musso]

Hello,

This is a mail I sent a month or so ago to the Release Engineering
internal mailing list.  Kunal Mehta pointed out it is worth publishing
for later reference.

It follows up the previous mail 'Jenkins API and Zuul Gearman'
https://lists.wikimedia.org/pipermail/qa/2015-September/002372.html


I wanted to highlight a couple nice features in Zuul:

* the merging queue and testing changes in parallel
* cross project dependencies


When folks +2 changes, they are inserted in a queue and Zuul craft merge
commits that speculate a change ahead in the queue will be merged.

So once you have change A, change B will be tested as if A is a success.
 Thus it runs in parallel:

 A
 A + B

If both run pass, both changes get merged.  If A fail, A + B is
cancelled and B reinserted in the queue.


That becomes a bit more complicated when you have several git repos
sharing the same queue.

 A on mediawiki/core
 B on extension

To test B, Zuul crafts a reference for mediawiki/core that contains A
and thus B is tested with:

 mediawiki/core @A
 extension @B

If A fails, the job for extension change B is canceled and reinserted
with mediawiki/core @master.


So B might well pass with mediawiki/core @master. But if A introduces an
incompatible change in mediawiki/core B will fail the test because it is
tested with A.


That is the purposes of the mediawiki-extensions-* jobs that test
together a chunk of extensions making sure they all work well together.


The doc is
http://docs.openstack.org/infra/zuul/gating.html


My point is that this feature caught a bunch of issue for Mobile already
and I dont think anything but Zuul propose such a system.

-- 
Antoine "hashar" Musso