Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Currently .gitlab-ci.yml calls out to .gitlab-ci/pipeline.yml to run kernel and functional tests. However, this is tricky to navigate in the GitLab UI, because the unit tests appear in the parent and other tests in a separate pipeline.
Steps to reproduce
Proposed resolution
Run the main set of tests in .gitlab-ci.yml itself.
Add a recursive call to .gitlab-ci.yml when running secondary test runs with different parameters.
Optionally, see if we can do test-only runs in a similar way.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3572375
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:
changes
Comments
Comment #2
longwaveNote: this might not be workable, but it's an idea I had while getting annoyed with clicking into child pipelines for the umpteenth time.
Comment #4
longwaveTurns out this wasn't that tricky after all, and IMHO the pipeline and test results pages are much easier to use this way.
Comment #5
longwaveShould we also move the repeat and performance tests into the "additional tests" stage?
Comment #6
borisson_I agree this looks much nicer. I think moving both the performance and repeat tests to additional tests make sense, that means most of the block will be ran by default?
Comment #7
mondrakeVery nice. Added some comments inline. NW for the fact that PHPStan job did not run, the other ones are for thought.
Comment #8
longwaveThanks for review, fixed the PHPStan job, responded to the other feedback.
I do not understand how GitLab sorts the job titles where emoji are involved, but I moved performance and repeat tests to "Additional tests" and the layout looks pretty good to me at the moment.
Comment #9
longwaveI also don't understand why the suppress deprecations flag isn't working on the W3C legacy tests - but only when they are run in a child pipeline?
Comment #10
mondrakeThe "PHPUnit Functional Javascript (non W3C legacy)" when run in the new 'Additional Tests' stage is not ignoring deprecations apparently.
Comment #11
longwaveFixed the issue with the legacy W3C tests, the webdriver config variable was not being overridden correctly.
Comment #12
mondrakeLet's go! Hard to predict if everything will work smooth for commit/daily/perf tests, but I guess we'll manage like we did in the past already for sweeping changes to the pipeline setup. Thanks
Comment #13
kentr commentedThere are merge conflicts.
Comment #14
longwaveRebased, the non-w3c tests are gone.
Comment #15
catchVery nice ux improvement for the pipelines. Let's try it and hope not too much breaks.
Committed/pushed to main, thanks!
Comment #19
nicxvan commentedI think this change is causing tests to run in the parent project rather than the issue fork, this prevents anyone but committers from rerunning tests.
I think we should revert this in the short term until we can resolve that.
Comment #22
dwwAlas, I don't think so. I didn't see anything in here that would affect which project the pipelines run in. I tried opening an MR to revert the commit. https://git.drupalcode.org/project/drupal/-/merge_requests/14921/pipelines shows a new pipeline, and it's got the old pipeline shape, but it's still running in the parent project, not the issue fork: https://git.drupalcode.org/project/drupal/-/pipelines/753666
So I'm 95% sure the problem is a change in GitLab behavior from a recently deployed "upgrade", and we need to escalate #3547431: Change global settings for all GitLab projects: fork pipelines and merge trains to major or critical (at least the part about "allow pipelines to run in parent project" to be set to false).
Comment #23
catchhttps://git.drupalcode.org/project/drupal/-/jobs/8664868 performance tests aren't happy.
Re-opening temporarily, haven't looked yet but assume it's a side effect of things moving around in the YAML.
Comment #25
longwaveMINK_DRIVER_ARGS_WEBDRIVERwas only set for the FunctionalJavascript tests, but it also needs to be set for the performance tests; hoisted it to the top level of the pipeline. If this is green I think it should fix the performance tests too.Comment #26
nicxvan commentedI still can't rerun these tests on the newest MR.
Comment #27
nicxvan commentedI added https://gitlab.com/gitlab-org/gitlab/-/issues/591657
Since it seems it could be due to the gitlab 18.9.1 update.
Comment #29
catchGoing to commit from needs review since there's no way to tell if this works otherwise, but we can see it hasn't broken anything via the MR pipeline.
Comment #32
nicxvan commentedI think this runs all stages even if the linting fails, we have an issue to allow this for draft MRs, but I think it's unintentional to always run all tests.
Comment #33
catchYes I think that's a side-effect rather than intentional. But also it's nice if we can eke a few seconds shorter pipelines out of this.
I'm wondering if instead of blocking tests on all lint stages, we could instead use https://gitlab.com/gitlab-org/gitlab/-/issues/23605 to cancel the pipeline when specific linting jobs fail (and maybe not include cspell in that). If one of those jobs fails quickly it would save the CI time on a full test run, but otherwise it'll start those jobs asap.
Comment #34
nicxvan commentedWe could also ask the DA if they've seen a significant increase in worker minutes since this merged.
The budget is what concerns me about this change without gating it behind the drafts.
It is slightly faster, but honestly the fact that we can't rerun tests or even view them on 11.x is the biggest blocker for me, not waiting a minute for stage one to complete.