The docker-composer env provides a node which is a docker container. We would need to run the Quibble as a container and using the same image used by CI. For this we would need another instance that has Docker running. I have filed T392294 to raise the quota.

This will require some caching mechanism for dependencies from npm/composer/etc

Change #1159484 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/config@zuul3] Experimental Quibble jobs

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

Change #1159484 abandoned by Hashar:

[integration/config@zuul3] Experimental Quibble jobs

Reason:

Demoed in mediawiki/core instead: I3a12baa14e953fc0464f59764a1b53a389f9a67b

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

Things to tackle:

• injecting dependencies (we use parameters functions)
• reproducing wmf-quibble* using job.required-projects and those projects would need the same job (that is not handled by Zuul)

In T392117#10943311, @hashar wrote:

Things to tackle:

• injecting dependencies (we use parameters functions)
• reproducing wmf-quibble* using job.required-projects and those projects would need the same job (that is not handled by Zuul)

(per meeting today)

In Zuul2.5 we injected MediaWiki dependencies via a python parameter function in zuul/parameter_functions.py (e.g., CirrusSearch depends on Elastica).

Per @Corvus: In new Zuul, we could have quibble look at the zuul projects list. We may need to have the quibble job encode that logic. Can also have base quibble job, and inherit from that job in fr ex an CirrusSearch job where it can add its dependencies. Can combine these ideas adding jobs and plugins. In Jenkins you'd have a job for the project plus what it's doing, but in Zuulv3+ you'd have one job that represents what it does and not what the job is running on; you will need quibble-php8, but not quibble-php8-mediawiki/quibble-php8-etc.