Screenshot of https://integration.wikimedia.org/zuul/
It seems that the reporting of successful test runs is blocked while there exist test runs that were initiated earlier, regardless of whether or not the runs are related in any way. See screenshot.
Version: wmf-deployment
Severity: normal
Attached:
I have enabled that behavior yesterday and it is totally unexpected although undocumented/unannounced. The screenshot shows three changes that have been +2ed and thus are entered by Zuul in a queue of patches to merge. They are:
Since extensions relies on mediawiki/core, if a change for it is about to land, we need to make sure that changes +2ed after will work with that change to mediawiki/core. It hasn't been merged yet but will certainly be if tests pass and can potentially break follow up changes.
When change 2 to Thanks enters the Zuul queue, Zuul craft a git reference pointing to the commit of mediawiki/core made by change 1. When preparing the git repositories for Thanks, Zuul will instruct to fetch Change 1 of mediawiki/core instead of the master branch. Thus Change 2 is tested with mediawiki/core @ Change 1.
The same goes for change 3, although in this case it is in a different branch (wmf). But Zuul is not smart enough to understand that they are unrelated and still enqueue it behind. The WikimediaEvents could well trigger a test depending on mediawiki/core @ master, thus it would need to be tested with mediawiki/core + Change 1.
I have documented the feature in Zuul: http://ci.openstack.org/zuul/gating.html#cross-projects-dependencies I have yet to figure out a place / way to document it for our developers. And I should definitely announce it.
That being said, I am quite happy you noticed the altered behavior :-]