|Resolved||hashar||T158674 Fatal error: Call to undefined function Wikibase\Client\Tests\RecentChanges\both() - on jenkins|
|Open||Paladox||T125343 Upgrade integration/composer to 1.4.3 stable|
|Resolved||Legoktm||T135161 Composer v1.1.0 generated vendor dirs will fail lint by PHP <5.6|
|Resolved||hashar||T136010 Update mediawiki/vendor.git's composer.json to exclude composer/* from lint checks|
|Resolved||Paladox||T136009 Add blacklist support to scap.tasks.check_valid_syntax linter|
|Resolved||Legoktm||T136021 Update git-change-in-head script to be able to allow us to ignore files|
|Resolved||Paladox||T159431 Upgrade of composer to v1.1.0 breaks some builds|
|Resolved||Paladox||T159469 Composer 1.1.0 is causing failures on phan jobs|
Change 267548 abandoned by Hashar:
Update composer to 1.0.0-alpha11
Krinkle / Paladox had a discussion on https://gerrit.wikimedia.org/r/259241 stating alpha11 is broken. We need a more recent version, lets track it on https://gerrit.wikimedia.org/r/#/c/270548/
Change 270548 abandoned by Paladox:
Update composer to 1.0.0 stable
I moved it https://gerrit.wikimedia.org/r/#/c/283852/ here.
Reason since it is a little hard to set permission of files in windows to work on Linux. I kept the symblinks in that patch and it passes.
Reverted in https://gerrit.wikimedia.org/r/#/c/286305/ because that composer version generates an autoloader that is not compatible with PHP 5.5.
10:08:07 PHP Parse error: syntax error, unexpected '.', expecting ')' in vendor/composer/autoload_static.php on line 10 10:08:07 Errors parsing vendor/composer/autoload_static.php 10:08:07 xargs: php5: exited with status 255; aborting
@JanZerebecki yes it is a bug, static loading should only be used on php 5.6 or above according to https://github.com/composer/composer/releases/tag/1.1.0-RC
So using composer 1.0.3 should be safe.
We will need to use config.platform in various places when using 1.1.0-RC. E.g. the build host for Wikidata is running PHP 5.6 but the result needs to be compatible with PHP 5.5.
Why shouldn't it lint those files?
Because we generate those files and not upstream (even though the exact upstream code does) we need to run the tests for those generated files.
The failure does not only happen when producing a build of composer, but when that version is used on the Wikidata build host to build Wikidata. When we use config.platform, where we use composer to produce a build that is saved, then it should work even when that is done with a newer PHP version. There are probably more place in gerrit.wikimedia.org that will need to do this, but when we changed vendor.git, Wikidata.git and composer.git to use config.platform we can upgrade to 1.1.0-RC.
Yes, perhaps it might still generate code that will fail the lint even when we would use config.platform. We will need to find out. There is also the linting step of scap during deployment (not sure if that only covers mediawiki-config or the whole tree including core and all extensions). Not doing linting seems like a bad idea, I'd like to avoid that.
We're pretty behind, and probably should jump to 1.6.x now...
@hashar reverted this last time noting that we also had to announce this, refresh docker images, and then refresh nodepool images. So we should schedule a date beforehand, merge the change, refresh the docker images, wait for any failures, and then let the daily auto refresh take care of the nodepool images. Does that sound reasonable?