Zuul can be used to ensure that every commit merged into a project has passed tests
and the project continues to work with its dependencies.
When a change or pull request is approved Zuul adds it to the gate pipeline.
This pipeline holds changes to be merged into their respective projects
in the order in which they are going to merge.
This ordering can be determined explicitly
if a user adds a "Depends-On" line to the commit message.
In that case, Zuul will make sure that the dependency is enqueued first
followed by the change that depends on it.
Or as in this case the order might simply be determined by the order
in which changes are approved by the project's developers.
In the example shown here
developers have approved two changes to Nova,
one change to Keystone,
followed by one more change to Nova.
As soon as a change is enqueued into the gate pipeline
Zuul starts running jobs for that change.
Each item in the pipeline represents a future state of its project
but also includes the future state of all the projects ahead of it in the queue.
So in this case, the tests which are running on the second Nova change
include the commit for that change as well as the first.
Nova and Keystone are tested together in the integration test job
so when that job runs on change #3
it is testing not only the Keystone change
but both Nova changes as well.
Inside that test job, it is as if all the changes ahead of it
in the queue have already merged.
In this way, Zuul tests the changes as they would be merged into the git repository
not simply as they were written.
Zuul runs all of these tests in parallel
but as soon as a job fails,
the future that Zuul predicted is no longer valid --
we know that change is not going to merge.
All of the tests for changes behind it in the queue are outdated
so Zuul cancels any running jobs for those changes.
Here we can see that not only has change #4 failed
but change #3 has as well.
Because #3 failed and is no longer eligible to merge
Zuul has invalidated the earlier test results for #4
and has re-started jobs for #4 with only changes #1 and #2 included this time.
Change #3 stays in the queue in case one of the changes ahead of it fails
but unless that happens it will not be merged.
As changes #1 and #2 complete their tests
each of them is merged into the Nova repository.
Once that is complete
it is safe to report the Keystone change #3 as having failed its tests
Finally, the tests for Nova change #4 are passing now
confirming that the earlier problem was due to the Keystone change
Zuul merges the final Nova change into the repository
once all tests are complete.