Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Follow-up to #3388365: Distribute @group #slow tests between test runners and mark more tests, there are a handful of stragglers.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3389839
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:
- 3389839-mark-some-more changes, plain diff MR !4882
Comments
Comment #3
catchOnce the worst culprits in #3389281: [meta] Refactor ultra-slow tests are done, any remaining slower tests tend to stick out towards the end of test runs. We probably want to mark most functional tests with more than 5 methods as #slow. The limit is that we don't wan to mark more tests slow than concurrency * parallel job runs, because that could push one of the very slow tests into the second batch of tests, which would then make the total run slower again.
So if we have 6 parallel functional test runs at concurrency 16 each, the absolute maximum number of @group #slow classes should be 6 * 16 = 96. Hopefully we'll end up with a lot lower than that of course.
Comment #4
catchAdded a few here.
Comment #5
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeems a lot of tests are slow haha. looks good though.
Comment #6
catchHad some commits locally to push, back to needs review but just more of the same.
https://git.drupalcode.org/project/drupal/-/pipelines/24325 shows the results (combined with several other issues) - 11m1s for a full test run.
If you look at the individual jobs on https://git.drupalcode.org/project/drupal/-/pipelines/24325 and ctrl-F for 'test run duration' you can see all the functional tests are finishing in 5-6 minutes. It is not perfectly balanced and there are still one or two tests that are 'ultra slow' and overshoot all the others, but it's a lot closer than without the MR when they could vary more like 4-8 minutes.
Kernel tests and Functional JavaScript tests are also 'balanced enough'. We can probably do some more work on kernel tests to mark the slow ones there, but could happen in a follow-up.
Comment #7
smustgrave CreditAttribution: smustgrave at Mobomo commentedKept this open for close to 24 hours in case you found more. But going to remark it now.
Comment #8
catchYes I am properly done for now :)
Comment #11
lauriiiLooks like we have 92 functional tests marked as #slow after this so the number of slow tests remain barely under the threshold mentioned in #3.
Committed 4316924 and pushed to 11.x. Thanks!
Comment #13
catchfwiw with functional test concurrency, the current numbers look like this:
HEAD:
After #3388952: Tweak gitlab CI concurrency, parallelism and test running order for 11 minute test runs it's lower but still high.
So still a lot of headroom to add #slow unless we significantly constrain the number of tests we run at once. Obviously it would be better if we made the actual tests less slow too so they don't need the tag.