It's not ideal, but we've done things like this before:

Thank you for having verified the job outcome @jnuche!

In T370380#10101864, @kostajh wrote:

The jobs for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1064132 just failed with Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies, is the work here related?

In T373114#10102048, @kostajh wrote:

if you want to experiment with things like parallelizing PHPUnit or Selenium tests, you generally assume that there's only one tests/phpunit or tests/selenium directory, and repos with multiple extensions will break that assumption.

In T373114#10102044, @Urbanecm_WMF wrote:

In T373114#10101990, @kostajh wrote:

(My 2c: having multiple extensions in the same repository causes headaches for other tooling's assumptions, and is nice to avoid if at all possible.)

Thanks for the comment. Just for curiosity, would you mind clarifying which kind of (other) headaches you mean here?

In T373114#10101990, @kostajh wrote:

(My 2c: having multiple extensions in the same repository causes headaches for other tooling's assumptions, and is nice to avoid if at all possible.)

(My 2c: having multiple extensions in the same repository causes headaches for other tooling's assumptions, and is nice to avoid if at all possible.)

The jobs for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1064132 just failed with Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies, is the work here related?

Mentioned in SAL (#wikimedia-releng) [2024-08-27T16:37:43Z] <James_F> Zuul: Configure the REL1_43 test and gate pipelines, for T372317

Change #1064006 merged by jenkins-bot:

[integration/config@master] Zuul: Configure the REL1_43 test and gate pipelines

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

Change #1067359 merged by jenkins-bot:

[mediawiki/core@REL1_39] installer: Support MW_SKIP_EXTERNAL_DEPENDENCIES in update.php

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

Change #1067359 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@REL1_39] installer: Support MW_SKIP_EXTERNAL_DEPENDENCIES in update.php

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

Change #1067358 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@fundraising/REL1_39] installer: Support MW_SKIP_EXTERNAL_DEPENDENCIES in update.php

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

Change #1063911 merged by jenkins-bot:

[mediawiki/core@master] installer: Support MW_SKIP_EXTERNAL_DEPENDENCIES in update.php

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

If possible, I'd rather avoid going the Wikibase route and changing how our extension is being loaded in production. Though it is an option on the table, too.

In T373114#10088735, @Michael wrote:

Thank you for your detailed thoughts! I somehow had hopes that a mechanism for that already would exist, but since it doesn't, I agree that (1c) sounds best from the options you listed.

Thank you for your detailed thoughts! I somehow had hopes that a mechanism for that already would exist, but since it doesn't, I agree that (1c) sounds best from the options you listed.

I took a look at possible approaches here. Since T189567: Phaseout CI mediawiki config / extensions_load.txt to load extensions, our CI runs the CLI installer with the with-extensions option. This means the installer scans the extensions (and skins) directories for extension.json files. Whenever it finds one, it adds it to the installer-generated LocalSettings.php. In other words: the set of extensions installed in CI is configured purely by making CI clone additional directories into an appropriate subdirectory. From there, the installer takes care of the rest. Internally, this happens in Quibble's code for installing MediaWiki on the CI side, and in CommandLineInstaller and friends on the MW side.

Introduced in rEWBA2edbce09c29b6ca33b8f5c05f7e98613e5c647cf (linked from T372458: Github Actions CI - pull from phabricator.wikimedia.org blocked 429).

In T256168#10082504, @bd808 wrote:

Was this task created in anticipation of the CI Jenkins instance being retired? The description here is very much about the "what" of the work, but seems to assume that everyone would already know the "why".

Change #1064477 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] qunit: Replace slow mw.messages reset with empty object reset

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

Was this task created in anticipation of the CI Jenkins instance being retired? The description here is very much about the "what" of the work, but seems to assume that everyone would already know the "why".

The job isn't run often, so all we know is that it completed successfully on July 3 (logs have been deleted), but failed on August 13. It looks like the image has been updated in that period, but that's for npm stuff that seems unrelated. It would be interesting to see the content of config.log, but I don't know how to add it to the build artifacts.