Description
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hashar | T158674 Fatal error: Call to undefined function Wikibase\Client\Tests\RecentChanges\both() - on jenkins | |||
| Resolved | Reedy | T125343 Upgrade integration/composer to 1.6.5 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 |
Event Timeline
The patch was merged and is now running the stable 1.1.0-rc composer release. Confirmed by https://gerrit.wikimedia.org/r/#/c/267546/ which would have failed the rebase if we were still using the old composer version.
Reverted in https://gerrit.wikimedia.org/r/#/c/286305/ because that composer version generates an autoloader that is not compatible with PHP 5.5.
https://gerrit.wikimedia.org/r/#/c/286298/
https://integration.wikimedia.org/ci/job/php55lint/10632/console
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 would composer 1.0.3 work or is it a bug in composer. Has it been reported upstream.
Also @JanZerebecki I doint know why it is linting vendor/composer files when it shoulden.
@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.
Change 286306 had a related patch set uploaded (by JanZerebecki):
Update composer to 1.0.3 stable
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 I thought that it would be up to upstream to lint anything in those files since they are auto generated.
@JanZerebecki maybe because when I re generated composer by composer update using php 7 it would have use the new optimised autoloader.
Maybe if we generate composer with php 5.5 it wont use the composer optimised autoloader.
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.
@JanZerebecki I think 1.1.0 would have work since the static autoload file would only be loaded if your using php 5.6, it generated it but would not have used it. We should ignore that file in the linter for php 5.5 or below.
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.
Change 320098 had a related patch set uploaded (by Paladox):
Add a script so we can disable loading the new autoload_static file
Change 320098 abandoned by Paladox:
Add a script so we can disable loading the new autoload_static file
Reason:
Yes but some of our linters doint support it expecially php -l.
Change 339645 merged by Hashar:
[integration/composer] Update composer to 1.1.0 with composer 1.1.0/PHP 5.5
Mentioned in SAL (#wikimedia-releng) [2017-03-02T09:18:02Z] <hashar> upgrading composer on permanent slaves for T125343 : salt -v '*slave*' cmd.run 'cd /srv/deployment/integration/composer && git pull'
Change 340780 had a related patch set uploaded (by Paladox):
[integration/composer] Update composer to 1.1.3
It looks like the update to composer 1.1.0 (perhaps only tangentially related?) has broken all jenkins runs to the CirrusSearch extension via the mwext-php70-phan-jessie job no longer being able to finish setting up: https://gerrit.wikimedia.org/r/#/c/340777/
Additionally it looks like not only CirrusSearch, perhaps all jobs using mwext-php60-phan-jessie? See also https://gerrit.wikimedia.org/r/#/c/340718/
Change 340791 had a related patch set uploaded (by Paladox):
[integration/composer] Update composer ti 1.3.2
Bump, this has been labeled "next" since February and there is a change sitting in Gerrit since March that is "Update composer to 1.4.2" but it's large, 18.000 lines changed or so.
https://gerrit.wikimedia.org/r/#/c/340791/
Does that have a chance to get merged?
Change 340791 merged by jenkins-bot:
[integration/composer@master] Update composer to 1.4.3
Change 395898 had a related patch set uploaded (by Paladox; owner: Paladox):
[integration/composer@master] Update composer to 1.4.3
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?
With I90544e3e5e488 we're now using 1.6.2 in mediawiki/vendor so this would be good to get done soon.
I'd suspect there's a 1.6.3 coming very soon to fix https://github.com/composer/packagist/issues/858 :D
Change 436705 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/composer@master] Update composer to 1.6.5
Yeah hire a few more people so we can afford to maintain the infra and deal with the upgrades aftermath :] More seriously, I am migrating extensions to Quibble and have no time to babysit a composer upgrade.
T125343#3876563 basically. The annoying part is going to be bumping all of the docker images manually...
Change 436852 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/config@master] Update docker images to use composer 1.6.5
Change 436705 merged by jenkins-bot:
[integration/composer@master] Update composer to 1.6.5
Change 436852 merged by jenkins-bot:
[integration/config@master] Update docker images to use composer 1.6.5
Change 436859 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/config@master] Update composer image to use composer 1.6.5
Change 436902 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/config@master] [WIP] Bump various docker images for composer update
Change 436859 merged by jenkins-bot:
[integration/config@master] Update composer image to use composer 1.6.5
Change 436902 merged by jenkins-bot:
[integration/config@master] Bump various docker images for composer update