Overview
https://git.drupalcode.org/project/gitlab_templates/-/work_items/3572380 was recently merged for all contrib modules using the default DA templates. Canvas implementation extends the default templates and adds their own jobs (which is totally fine), however some of those jobs always run, no matter what.
Checking the usage over the last week alone, canvas is on par with Drupal core:

This is probably due to the volume of issues and MR being worked on each day, so again, the above is not a bad thing, but something to think about.
Last, I see that there is already a "*manual-rule", which is exactly what has been done in the gitlab_templates,
Proposed resolution
I think the idea would be to review which jobs could use the "*manual-rule" that currently do not use it.
I don't know enough about the whole pipeline to know which job is relavant where, so I'll let the people that know suggest possible improvements, if any.
User interface changes
If implemented, some pipeline jobs would need to be manually triggered.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | horror CI.gif | 4.69 MB | wim leers |
| #2 | Screenshot 2026-04-21 at 12.56.21.png | 83.68 KB | fjgarlin |
| #2 | Screenshot 2026-04-21 at 12.54.22.png | 120.62 KB | fjgarlin |
| Screenshot 2026-04-21 at 09.45.48.png | 70.76 KB | fjgarlin |
Issue fork canvas-3585979
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
fjgarlin commentedAlso, seeing the per-job breakdown (see the images), there are many cypress and playwright jobs that reach the 30 min timeout, so these jobs are likely to be run again (either automatically or manually). Is there a way to parallelize these jobs so they take max 10-15 min?
Comment #5
penyaskitoOne impediment we have is Gitlab absence of support for exclude/negation rules.
e.g. we could reduce the amount of jobs easily with something like
> if ONLY packages/* change, skip X jobs.
Gitlab supports
> if packages/* change, run X jobs.
Flipping the condition would force us to maintain (and hardcode) an allowlist: meaning every new file type or directory could become a silent trap for skipping the job that shouldn't be skipped.
Comment #6
penyaskitoNeeds review for !944, that's an easy win both for the team speed + reducing the number of timeouts (aka people hitting retry).
Can't claim this would help with the DA spend though, as there will be extra jobs per MR. Not sure which one outweighs the other.
Comment #7
fjgarlin commented1 jobs at 30 minutes equals 6 jobs at 5 minutes, but the former could be "retried" if it goes over the 30 min, so that's an improvement. Every bit counts.
Comment #8
fjgarlin commentedAs per the reverse logic: https://gitlab.com/gitlab-org/gitlab/-/work_items/198688
Comment #9
wim leers#3529128: Speed up PHPUnit on CI; stop relying on drupal.org composer template should help drastically with the PHPUnit CI jobs.
Comment #10
wim leersRTBC'd the first MR.
Comment #12
penyaskitoMerged !944. Leaving as NW as there's more to fix here.
Comment #13
penyaskito#3586655: CI: do not run E2E tests when zero JS or PHP is modified; reorganize `rules` is definitely a subset of this.
Comment #15
wim leersI am not convinced that the script in !995 really helps? It's a single line we're expected to modify. I defer to @justafish.
Comment #16
wim leersComment #17
wim leers#3586655: CI: do not run E2E tests when zero JS or PHP is modified; reorganize `rules` just landed, and should make a serious dent in this!
Comment #18
wim leersComment #19
wim leersAfter #3529128: Speed up PHPUnit on CI; stop relying on drupal.org composer template lands, I think we should consider making:
PHPUnit (11.2)run on all DBsPHPUnit (11.3)run only on SQLiteOr vice versa.
Thoughts?
EDIT: to clarify, I mean for merge commits (aka push to
1.x). Currently both 11.2 and 11.3 run all tests on all 4 DBs.Comment #20
wim leers@justafish's #3586660: CI: Add additional caching to GitLab CI pipelines should also make a difference here: same # of CI jobs, but they should run faster.
Comment #21
wim leers#3529128: Speed up PHPUnit on CI; stop relying on drupal.org composer template is in!
Next up: #3587819: Optimize which PHPUnit CI jobs run: which version (11.2 vs 11.3) + DB combos, for #19.
Comment #22
wim leers@fjgarlin: Yesterday's last commit had an absolutely terrifying CI pipeline. Why? See attached GIF. Pipeline URL: https://git.drupalcode.org/project/canvas/-/pipelines/808898
In part due to our PHPUnit CI jobs taking >30 mins. That's fixed as of today: #3529128: Speed up PHPUnit on CI; stop relying on drupal.org composer template landed.
However, it also appears to be in part due to infra instability. I've seen this happen many times in the past. But perhaps now is the time to investigate it? It manifests like this:
— https://git.drupalcode.org/project/canvas/-/jobs/9597857
Any idea what's going on? Is this a known d.o GitLab CI problem? Is it something Canvas is doing?
Comment #23
fjgarlin commentedOh wow, that is indeed horrifying! However, the timestamps coincide with yesterday's security update to the CI runners (https://drupal.slack.com/archives/C51GNJG91/p1777507813295379) so I think, in a way, it was just bad timing.
If this happens again at a time when there aren't any updates happening, then we need to investigate for sure. But from the above output, it seems that the jobs were running and the containers were just killed, which most likely retriggered the jobs to run (if not automatic it was done manually, hence the fully green pipeline).
If this was posponed just based on this, I guess it can be unposponed.
Comment #24
wim leers#3587819: Optimize which PHPUnit CI jobs run: 1) nightly: ALL version+DB combos, 2) 1.x/merged MRs: 11.3 all DBs, 11.2 only SQLite is also in. Now I'd like to wait and see the results 😊