+1, this would really help.

This would not help in the case of extensions with dependencies,

Speaking of which, it would be great if CI used the "directory_list" option to clone whatever repos are needed. Even better, a specific option for extensions/skins in ConfigBuilder (or in a JSON/yaml file, if we want to do that instead, as per T254571)

Change 692744 had a related patch set uploaded (by Legoktm; author: Legoktm):

[integration/config@master] dockerfiles: Have phan job pass if .phan/config.php is not present

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

Change 693475 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] jjb: Switch mediawiki-phan jobs to images that pass when unconfigured

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

Change 692744 merged by jenkins-bot:

[integration/config@master] dockerfiles: [mediawiki-phan*] Have job pass if .phan/config.php is absent

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

Mentioned in SAL (#wikimedia-releng) [2021-05-21T17:59:38Z] <James_F> Docker: Publishing mediawiki-phan* images where the job passes if .phan/config.php is absent T283097

Change 693477 had a related patch set uploaded (by Jforrester; author: Jforrester):

[integration/config@master] Zuul: Add phan to all extensions and skins

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

Change 693475 merged by jenkins-bot:

[integration/config@master] jjb: Switch mediawiki-phan jobs to images that pass when unconfigured

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

Change 693477 merged by jenkins-bot:

[integration/config@master] Zuul: Add phan to all extensions and skins

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

Mentioned in SAL (#wikimedia-releng) [2021-05-21T18:30:22Z] <James_F> Zuul: Add phan to all extensions and skins T283097

Announced at https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/F2LIN5IFQHCRA6ZAMCLR7U5X2GZBWYYY/

One question about this criterion,

The job would check if .phan/config.php exists, if not, it would return 0 and quickly finish

Currently the job takes 2 minutes to provision before testing for phan/config.php. Are we constrained to adding logic within the mediawiki-phan container? I see the guard condition comes early in the mediawiki-phan docker image, this seems to be as good as we can get with the given approach.

What about launching the phan job from within quibble, which already supports conditional jobs? For comparison, npm test and composer test already follow the same structure: if configuration file exists then launch subprocess.

In T283097#7104394, @awight wrote:

One question about this criterion,

The job would check if .phan/config.php exists, if not, it would return 0 and quickly finish

Currently the job takes 2 minutes to provision before testing for phan/config.php. Are we constrained to adding logic within the mediawiki-phan container? I see the guard condition comes early in the mediawiki-phan docker image, this seems to be as good as we can get with the given approach.

What about launching the phan job from within quibble, which already supports conditional jobs? For comparison, npm test and composer test already follow the same structure: if configuration file exists then launch subprocess.

The plan is to move the phan work into the main composer test job, which will mean for less magic and make for easier migration to GitLab (where all CI is going to be configured in-repo). It's a tad irritating, but it's not a big waste as the vast bulk of development happens on repos with phan configured.