core for release branches (where we don't test with vendor)
Open, HighPublic
Actions

Assigned To

None

Authored By

	JanZerebecki
	Sep 22 2015, 3:11 PM

Description

Make sure composer.json in mediawiki/vendor matches with mediawiki/core. Or put another way, when running composer of core its deployment branch it should result in a vendor directory that matches with mediawiki/core. This might also involve creating a composer.local.json in core that merges composer.json from all extensions during branching (need to modify the tools that are used for cutting the deployment branch).

The following dependencies do exist in vendor but are not listed under require(-dev) in core directly:

"firebase/php-jwt": "2.1.0",
"kzykhys/pygments": "1.0",
"ruflin/elastica": "2.2.0",
"symfony/process": "2.7.3",

These were added in require-dev to core because they broke running the tests ( fixed in https://gerrit.wikimedia.org/r/#/c/240067/ ) :

"monolog/monolog": "1.14.0",
"nmred/kafka-php": "0.1.4",
"wikimedia/avro": "1.7.7",

Related Objects

Mentioned In: T312059: Wrong version of guzzle shipped with 1.37.3 (breaks update.php)
T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present
Mentioned Here: T295175: Have at least one job running REL1_XX with it's appropriate vendor repo
T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present
T179663: What happens if the Wikibase project specifies a version of a library outside of the range included in mediawiki-vendor?

Event Timeline

JanZerebecki created this task.Sep 22 2015, 3:11 PM

JanZerebecki raised the priority of this task from to Needs Triage.

JanZerebecki updated the task description. (Show Details)

JanZerebecki added a project: MediaWiki-Vendor.

JanZerebecki subscribed.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 22 2015, 3:11 PM

JanZerebecki added a parent task: T101123: automatically build and commit mediawiki/vendor (composer).Sep 22 2015, 3:12 PM

Turnstep subscribed.Dec 7 2015, 4:52 PM

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 7 2015, 4:52 PM

I'm not really sure what the state of this ticket is or if we should just close it given it is from 2015

Rephrasing this to be about the original problem. Feel free to close if such test has already been added since. I seem to recall that either PHPUnit or maintenance/update.php already ensures this?

Krinkle removed a parent task: T101123: automatically build and commit mediawiki/vendor (composer).Oct 11 2017, 8:53 PM

Krinkle moved this task from Inbox to Checkers on the MediaWiki-Core-Tests board.Jan 25 2019, 11:00 PM

Surely we implicitly test this, because we test MediaWiki core patches with both the vendor.git checkout and a native composer install run in CI?

RhinosF1 subscribed.Mar 6 2021, 6:18 PM

In T113360#6889415, @Jdforrester-WMF wrote:

Surely we implicitly test this, because we test MediaWiki core patches with both the vendor.git checkout and a native composer install run in CI?

We would only actually check this if some composer check is run during CI for core when the git checkout of mediawiki-vendor is used, that would check the validity of the installed libraries. (mediawiki also does some sort of check to see if composer.lock is up to date I think? maybe that comes into play too)
Also all deployed extensions would need to be included for this to fully check (Not sure if this is yet done in gate?)

I think T179663: What happens if the Wikibase project specifies a version of a library outside of the range included in mediawiki-vendor? is actually my very own version of this task?
I feel T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present is also related

Addshore mentioned this in T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present.Mar 17 2021, 11:58 AM

In T113360#6889415, @Jdforrester-WMF wrote:

Surely we implicitly test this, because we test MediaWiki core patches with both the vendor.git checkout and a native composer install run in CI?

T295175: Have at least one job running REL1_XX with it's appropriate vendor repo

Jdforrester-WMF renamed this task from Ensure with test that composer.json matches between mediawiki/vendor and mediawiki/core to Ensure with test that composer.json matches between mediawiki/vendor and mediawiki/core for release branches (where we don't test with vendor).Jun 24 2022, 11:51 AM

Reedy mentioned this in T312059: Wrong version of guzzle shipped with 1.37.3 (breaks update.php).Jul 5 2022, 9:21 PM

Addshore unsubscribed.Jun 27 2023, 12:39 PM

Ensure with test that composer.json matches between mediawiki/vendor and mediawiki/core for release branches (where we don't test with vendor)Open, HighPublicActions

Description

Related Objects

Event Timeline

Ensure with test that composer.json matches between mediawiki/vendor and mediawiki/core for release branches (where we don't test with vendor)
Open, HighPublic
Actions