https://bugzilla.wikimedia.org/show_bug.cgi?id=71029
--- Comment #1 from Antoine hashar Musso has...@free.fr ---
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:
1) https://gerrit.wikimedia.org/r/#/c/154868/ mediawiki/core [master]
2) https://gerrit.wikimedia.org/r/#/c/160813/ mediawiki/extensions/Thanks
[master]
3) https://gerrit.wikimedia.org/r/#/c/161380/
mediawiki/extensions/WikimediaEvents [wmf/1.24wmf21]
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 :-]
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
