Update Composer >=1.9.3 for CI jobs
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	bd808
	Apr 5 2020, 8:56 PM

Description

We recently added support in Jenkins jobs for passing an auth token along with requests generated by Composer to the GitHub APIs (T106452: Composer activity from Cloud VPS hosts can be rate limited by GitHub). This seems to be working, but it is also likely to stop working on or before November 13, 2020. This will be caused by an upstream feature deprecation at GitHub.

The fix needed on our side is to upgrade Composer to a newer version which is following the announced change. Composer version 1.9.3 includes the required changes. It has been nearly 2 years since we updated Composer (T125343: Upgrade integration/composer to 1.6.5 stable), so it is probably past due anyway. At the moment I write this, v1.10.1 is the most current Composer release.

Details

Project	Branch	Lines +/-	Subject
integration/composer	master	+10 K -4 K	Update composer to 1.10.15
integration/config	master	+58 -58	jjb: Move to images based on composer 1.10.5 phar, not 1.6.5 local repo
integration/config	master	+256 -31	dockerfiles: [composer-php70] Replace integration/composer repo with phar
integration/config	master	+168 -0	dockerfiles: [composer-php70] Update composer to v1.10.1

Customize query in gerrit

Related Objects

Mentioned In: T249464: Replace integration/composer with a composer.phar in CI usage
Mentioned Here: T106452: Composer activity from Cloud VPS hosts can be rate limited by GitHub
T125343: Upgrade integration/composer to 1.6.5 stable

Event Timeline

bd808 created this task.Apr 5 2020, 8:56 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 5 2020, 8:56 PM

Change 586142 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[integration/composer@master] Update composer to 1.10.1

https://gerrit.wikimedia.org/r/586142

gerritbot added a project: Patch-For-Review.Apr 5 2020, 9:04 PM

Seems we're still using composer with PHP 5.6 images?

https://github.com/wikimedia/integration-config/tree/e0982e0c4573e6dd32346d5e6499a881277f98d9/dockerfiles

In T249461#6030585, @Reedy wrote:

Seems we're still using composer with PHP 5.6 images?

https://github.com/wikimedia/integration-config/tree/e0982e0c4573e6dd32346d5e6499a881277f98d9/dockerfiles

v1.10.1 supports PHP >=v5.3.9 so this should not be a problem.

In T249461#6030588, @bd808 wrote:

In T249461#6030585, @Reedy wrote:

Seems we're still using composer with PHP 5.6 images?

https://github.com/wikimedia/integration-config/tree/e0982e0c4573e6dd32346d5e6499a881277f98d9/dockerfiles

v1.10.1 supports PHP >=v5.3.9 so this should not be a problem.

It was more updating the platform restraint in composer.json for that repo. See my comment. We presumably don't need a version so low?

In T249461#6030590, @Reedy wrote:

It was more updating the platform restraint in composer.json for that repo. See my comment. We presumably don't need a version so low?

See my comment in response. :) Matching the version constraints used in the upstream project seems prudent. If we pull in newer dependencies than they test against it will be difficult to get them to work on any issues this may introduce.

I honestly am not sure why we don't just use the upstream PHAR file, but I won't try to readjudicate that decision at this time.

In T249461#6030592, @bd808 wrote:

I honestly am not sure why we don't just use the upstream PHAR file, but I won't try to readjudicate that decision at this time.

This repository holds Composer and its dependencies. It is meant to safely deploy Composer on the Wikimedia cluster since:

we can NOT download from third parties

there is no Debian package for Composer (until Debian Stretch, which has 1.2.2)

Even in buster it's 1.8.4, so that's too old - https://packages.debian.org/buster/composer

We still can't download from third parties... But bundling the phar into integration/config seems sensible

Reedy mentioned this in T249464: Replace integration/composer with a composer.phar in CI usage.Apr 5 2020, 9:33 PM

In T249461#6030592, @bd808 wrote:

I honestly am not sure why we don't just use the upstream PHAR file, but I won't try to readjudicate that decision at this time.

Storing binary files in git isn't the greatest, and at the time we were using git to deploy composer to the various CI instances. But since we use docker now we can just keep the sha256sum in the repo and download the phar during the image build process and verify it then. 👍 from me.

Change 586155 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/config@master] dockerfiles: [composer-php70] Update composer to v1.10.1

https://gerrit.wikimedia.org/r/586155

Change 586155 abandoned by Reedy:
dockerfiles: [composer-php70] Update composer to v1.10.1

https://gerrit.wikimedia.org/r/586155

Change 586154 had a related patch set uploaded (by Reedy; owner: Reedy):
[integration/config@master] Replace integration/composer repo with composer.phar

https://gerrit.wikimedia.org/r/586154

Change 586154 merged by jenkins-bot:
[integration/config@master] dockerfiles: [composer-php70] Replace integration/composer repo with phar

https://gerrit.wikimedia.org/r/586154

Change 586142 merged by jenkins-bot:
[integration/composer@master] Update composer to 1.10.15

https://gerrit.wikimedia.org/r/586142

Change 588032 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[integration/config@master] jjb: Move images to ones based on composer 1.10.5 phar not 1.6.5 local repo

https://gerrit.wikimedia.org/r/588032

Change 588032 merged by jenkins-bot:
[integration/config@master] jjb: Move to images based on composer 1.10.5 phar, not 1.6.5 local repo