[00:47:54] 10Quibble, 10Design-Systems-Team, 10MediaWiki-ResourceLoader, 10Performance-Team: CI failure - TypeError: Cannot read property 'registerCompiler' of undefined - https://phabricator.wikimedia.org/T330314 (10Krinkle) 05Open→03Resolved [08:44:36] hashar: I was wondering how come quibble doesn't have `phan` as one of its commands. e.g. we have {thing}-{php}-phan-docker in CI, but that uses Quibble only for clone & setup, then it calls `run-generic.sh` which runs `vendor/bin/phan -d . --long-progress-bar "$@" --require-config-exists`. Should we implement PhanCommand in Quibble? then I could get early warnings when that job fails for one of my patches :) [08:45:08] or, we could use quibble's custom command ability to call `run-generic.sh`? [09:19:15] kostajh: historical reasons I believe [09:19:40] phan got first introduced for mediawiki/core and went with a dedicated image cause Phan more or less the php-ast extension [09:20:07] that extension is a bit tricky, Phan has a minimum version requirement for ast which is not necessarly shipped by Debian [09:20:29] and Phan eventually required php 7.4 while Quibble required 7.2 [09:20:32] something like that [09:20:52] then Phan usage got generalized for extensions/skins and since there are cross repo dependencies we went to use Quibble to clone the repos [09:21:58] for a given change, we would want to run Phan only once so I guess if we had a phan step in Quibble that would mean adding `--skip=phan` to all jobs [09:22:26] and create one that has `--run=phan` which would end up being more or less the same thing as the current `{thing}-{php}-phan-docker` template [09:23:25] it also add a requirement to have php-ast installed, though phan has a polyfill parser which is purely php [09:23:30] so it is an optional dep [09:53:42] maybe we should use the UserScripts command, then, so we don't have to update a bunch of jobs [09:56:09] oh right, I see what you meant that it has its own image [09:56:34] I guess nowadays the php-ast issue is not as much of a problem [09:58:59] anyway, probably more trouble than it's worth. though phan failures were one of my motivations for the "early warning" notices, b/c phan is not always easy to run locally [09:59:40] I republished https://phabricator.wikimedia.org/phame/post/view/302/ci_get_notified_early_when_a_job_fails/ btw :) [10:44:36] another way would be to add two steps process for testing [10:45:03] at first trigger all the jobs that only clone a single repo and are usually quite fast [10:45:12] have them vote something like test +1 [10:45:32] and when that is received triggers a new Zuul pipeline which runs the ingration tests and would vote integration +1 [10:45:55] but for gate, we would still need to run them all in the same pipe [10:46:23] I once try to use dependencies between jobs like it is done on integration/quibble which first run tox and then run the fullrun jobs. The yaml looks something like: [10:46:28] - tox-docker: [10:46:37] - quibble-fullrun [10:46:39] - quibble-fullrun-sqlite [10:46:53] and when tox-docker fails, nothing else is run [10:47:15] but that hierarchy of jobs can not be defined when Zuul job templates are used :-\ [11:53:15] yeah it would be cool if we could e.g. 1) clone the repo(s) then 2) install dependencies then 3) start running tests, but phase 3 makes use of the work already done in phase 1 and 2 [12:53:17] we would need to be able to store artifacts or somehow transfer them between builds/nodes [19:17:39] ack [19:17:48] do we need to support so many python versions, btw? [19:18:12] it would be nice to use subprocess.run from python 3.10