Last modified: 2014-10-24 13:51:24 UTC
Created attachment 16536 [details] Build log of https://gerrit.wikimedia.org/r/162010 for UploadWizard @ wmf/1.24wmf22 When proposing a change for an extension against a wmf branch, Zuul cloner ends up setting the mediawiki/core repo to the extension repo and thus we no more have any mediawiki install. The job thus fails with: Could not open input file: maintenance/install.php Zuul clone the repository in order: zuul.CloneMapper:Mapping projects to workspace... mediawiki/core -> src mediawiki/vendor -> src/vendor mediawiki/extensions/UploadWizard -> src/extensions/UploadWizard In mediawiki/core wmf branch, src/extensions/UploadWizard is an existing directory (it is a submodule destination) and the git repository is actually mediawiki/core! So Zuul cloner ends up setting /src (where mediawiki/core lives) to point to UploadWizard and reset the content. The workspace /src/ ends up being simply UploadWizard.
I am 100% focusing on this issue which is a bug/lack of feature in Zuul
Patch proposed upstream: https://review.openstack.org/#/c/123437/ Will let Zuul cloner clone a repo whenever /.git/ does not exist.
The patch I wrote fails with python2.6. I have no idea whether it is py2.6 only issue (GitPython could have a different behavior) or if it highlight a potential race condition which would end up hitting us.
Command line to reproduce (ex on lanthanum.eqiad.wmnet) ZUUL_PIPELINE=gate-and-submit ZUUL_UUID=38f010811238413d8cf7f5769b50b1aa ZUUL_CHANGE_IDS=162010,1 ZUUL_PATCHSET=1 ZUUL_BRANCH=wmf/1.24wmf22 ZUUL_REF=refs/zuul/wmf/1.24wmf22/Zd1cf5a14be22471abd111a869e5e9af0 ZUUL_COMMIT=e37096a1fade03449d80e13aa8e8b218728cbbde ZUUL_URL=git://zuul.eqiad.wmnet ZUUL_CHANGE=162010 ZUUL_CHANGES=mediawiki/extensions/UploadWizard:wmf/1.24wmf22:refs/changes/10/162010/1 ZUUL_PROJECT=mediawiki/extensions/UploadWizard /usr/local/bin/zuul-cloner --color --verbose --branch wmf/1.24wmf22 --map /srv/deployment/integration/slave-scripts/etc/zuul-clonemap.yaml https://gerrit.wikimedia.org/r/p mediawiki/core mediawiki/vendor mediawiki/extensions/UploadWizard --workspace src
Tested on integration-slave1001 with: tox -e venv -- ZUUL_PIPELINE=gate-and-submit ZUUL_UUID=38f010811238413d8cf7f5769b50b1aa ZUUL_CHANGE_IDS=162010,1 ZUUL_PATCHSET=1 ZUUL_BRANCH=wmf/1.24wmf22 ZUUL_REF=refs/zuul/wmf/1.24wmf22/Zd1cf5a14be22471abd111a869e5e9af0 ZUUL_COMMIT=e37096a1fade03449d80e13aa8e8b218728cbbde ZUUL_URL=git://zuul.eqiad.wmnet ZUUL_CHANGE=162010 ZUUL_CHANGES=mediawiki/extensions/UploadWizard:wmf/1.24wmf22:refs/changes/10/162010/1 ZUUL_PROJECT=mediawiki/extensions/UploadWizard zuul-cloner --color --verbose --branch wmf/1.24wmf22 --map /srv/deployment/integration/slave-scripts/etc/zuul-clonemap.yaml https://gerrit.wikimedia.org/r/p mediawiki/core mediawiki/vendor mediawiki/extensions/UploadWizard --workspace /tmp/hasharbug I end up with: $ find /tmp/hasharbug -type d -name .git /tmp/hasharbug/.git /tmp/hasharbug/vendor/.git /tmp/hasharbug/extensions/UploadWizard/.git \O/
I have applied the patch on gallium/lanthanum. Wiped the workspace and retriggered a previously failing build. It passes now: https://integration.wikimedia.org/ci/job/mwext-UploadWizard-testextension/43/console Lowering priority. Upstream patch still pending though.
Switched mwext-UploadWizard-qunit back to use Zuul cloner ( https://gerrit.wikimedia.org/r/#/c/161459/ ). I have wiped the workspace and retriggered a wmf branch based change: https://integration.wikimedia.org/ci/job/mwext-UploadWizard-qunit/397/console $ find /srv/ssd/jenkins-slave/workspace/mwext-UploadWizard-qunit -type d -name .git /srv/ssd/jenkins-slave/workspace/mwext-UploadWizard-qunit/src/.git /srv/ssd/jenkins-slave/workspace/mwext-UploadWizard-qunit/src/extensions/UploadWizard/.git /srv/ssd/jenkins-slave/workspace/mwext-UploadWizard-qunit/src/vendor/.git All good.
Upgraded Zuul on all integration labs instances
This is fixed on our installation. Pending upstream patch to be merged in.
The patch I proposed to upstream https://review.openstack.org/#/c/123437/ was blocked because the tests under python2.6 were broken. The root cause is a different version of git being used there (before git 1.7.8) which broke an assertion. I have updated my patch and it now passes :-]
