Based in Nantes, France CET/CEST (UTC+1, UTC+2)
Main IRC channel is #wikimedia-releng
@greg cawiki and hewiki are on wmf.2, if needed they also need to revert.
Seems to run properly now as can be seen on https://gerrit.wikimedia.org/r/#/c/355067/
Well done!! From a quick chat I had with @Jdlrobson , it would be rather nice to have that RL linter to be generalized so it can benefits other extensions. Maybe the linter could be upstreamed to mediawiki/core ?
I guess now we can switch CI from HHVM 3.12. to the latest 3.18 you have build? :-}
Gilles and I have recheck the couple jobs that still had a verified -1 due to the issue:
I have migrated that job from trusty to jessie. It uses HHVM and the version on Trusty is obsolete / got removed
I thought I had fixed it :(
Should be good now :)
I have removed HHVM from the Trusty imag entirely with https://gerrit.wikimedia.org/r/#/c/355187/ So it is no more a problem :)
Thank you @Dereckson for the follow up. I have completely missed following up on this task :(
Reopening, wrong task / I am confused.
Will stick to deb packages for now. There is only a couple host that relies on it and we only upgrade it once in a while.
Indeed the composer test step has been merged with the jobs running PHPUnit tests. Happened viaT161895.
The mwdeploy user requires (or required at some point) to have the same UID on all the deployment target. To achieve that, we went to add the user in LDAP:
dn: uid=mwdeploy,ou=people,dc=wikimedia,dc=org uid: mwdeploy objectClass: person objectClass: inetorgperson objectClass: organizationalPerson objectClass: ldappublickey objectClass: shadowaccount objectClass: posixaccount objectClass: top loginShell: /bin/bash uidNumber: 603 gidNumber: 603 sn: mwdeploy homeDirectory: /home/mwdeploy cn: mwdeploy
This is premature. Will come to it when it is time :-}
00:03:02.899 ext.cx.tools.mtabuse 00:03:02.900 ✔ MT Abuse - isAbuse method tests 00:04:02.917 18 05 2017 05:14:22.124:WARN [Chrome 57.0.2987 (Linux 0.0.0)]: Disconnected (1 times), because no message in 60000 ms.
I did a recheck on the Gerrit change https://gerrit.wikimedia.org/r/#/c/353929/ and it eventually passed just fine https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-selenium-jessie/1408/console
I have force regenerated the Jenkins job mediawiki-core-qunit-selenium-jessie . The web gui now shows:
We had a single job handling both qunit and selenium tests with 48a1955569bf9cca5bd4290526cb2ee5f9abe108 . Supposedly when there is no junit output, the job should just gracefully pass:
+ - junit: + results: 'log/junit*.xml,log/WDIO.xunit*.xml' + # Qunit does not generate Junit file and we might skip selenium + allow-empty-results: true
php5-gmp is not available yet on the CI machine. The provisioning of Trusty images on Nodepool is broken due to an unrelated puppet mistake.
I also added an iOS test to hopefully give us early warning any time beta cluster's mobileview section html output changes: https://phabricator.wikimedia.org/T165207
The CI job expects composer.json file to have a scripts.test command. Sorry about that!
@MoritzMuehlenhoff has pushed HHVM 3.12 to 'experimental' and I wrote a few rules to pin that version. The Nodepool instances are thus on 3.12:
jenkins@ci-jessie-wikimedia-660007:~$ apt-cache policy hhvm hhvm: Installed: 3.12.14+dfsg-1+wmf1 Candidate: 3.12.14+dfsg-1+wmf1 Package pin: 3.12.14+dfsg-1+wmf1 Version table: 3.18.2+dfsg-1+wmf2 1002 1001 http://apt.wikimedia.org/wikimedia/ jessie-wikimedia/main amd64 Packages *** 3.12.14+dfsg-1+wmf1 1002 1 http://apt.wikimedia.org/wikimedia/ jessie-wikimedia/experimental amd64 Packages 100 /var/lib/dpkg/status
Should be all fixed in production now. Deployed with @Jdlrobson .
@Reedy investigation at https://github.com/facebook/hhvm/issues/7779 shows an issue within XmlReader. That seems very close to T156923#2992912 which has hit us with HHVM 3.12.11. By that I mean the stacktrace looks alike.
Might be T156923: New HHVM 3.12.11 segfault at end of MediaWiki PHPUnit tests surfacing again which mentionned XMLReader.
CI instances have been rollbacked to the last known snapshot which uses HHVM 3.12.14. I have confirmed it on a job triggered after the rollback. So CI is fine right now.
Jessie instances are now being booted from snapshot-ci-jessie-1494425642 which should have the previous HHVM version.
The snapshots we have:
That is caused by the upgrade of HHVM T158176: Build / migrate to HHVM 3.18. 3.18 has been uploaded to apt.wikimedia.org under jessie-wikimedia/main and hence the CI instances are now using it
Potentially due to namespaceDupes.php, any page in NS_MAIN that started with Autor ended up being moved to namespace 104 which is for index of pages.
Sorry I have missed the notifications.
I can't tackle that one sorry :-( Though hypothetically it is something we can pair up on next week. Would be an opportunity for me to level up.
And OpenStackManager uses /bin/bash 6360ed954ee5488d0a4be3bcc156bdc0bc7543f4
-$wgOpenStackManagerLDAPDefaultShell = '/usr/local/bin/sillyshell'; +$wgOpenStackManagerLDAPDefaultShell = '/bin/bash';
I have excluded the servicegroups based on an earlier comment.
It is already at the highest priority and in a standalone queue.
Yup looks good to me after the European SWAT. Kudos on the config :-}
All links/articles fixed:
There are a few extensions having a composer.json file but that lacks a scripts.test entry. With the testextension job now invoking composer test that would fail.
The Swift servers have been rebuild to use Jessie.
I have definitely havent updated composer.lock at all, sorry.
Well done @zeljkofilipin !