Problem/Motivation
Based on parent issue we concluded that limiting the resource usage to the actual usage can be done without any changes to pipeline speed. This will save a lot of CPU time (and VM's) so we should at least start there.
Steps to reproduce
Check pipeline, its still fast ;)
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3398321-11.patch | 4.31 KB | gauravvvv |
Issue fork drupal-3398321
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 #3
bbralaComment #4
bbralaComment #5
bbralaComment #7
catchI made some commits here but the only eventual change was going from 12 cores for functional tests to 24. At 20 or less we were seeing spikes where running tests would spike from ~6m30s to ~9m seemingly somewhat at random (i.e. not a gradual degradation but a sudden drop off). As a first step this is great, and we can try to do more in follow-ups like trading off parallel vs. concurrency as well as discussing with the infra team.
Comment #10
catchGoing ahead and committing this because the quicker we do that, the quicker we'll get feedback from the DA on what the effect on runners is.
Committed/pushed to 11.x and cherry-picked to 10.2.x, thanks!
Doesn't apply to 10.1.x but we should probably try to backport it there, so moving to 'to be ported'.
Comment #11
gauravvvv commentedI have re-rolled the patch fro 10.1.x. please check
Comment #12
bramdriesenThanks @Gauravvvv, I reviewed the patch and verified that all changes are at the correct place and have the correct value for the correct block. Think this is good to go into 10.1.x. Setting to RTBC since it's already reviewed before the other two commits.
Comment #14
catchCommitted/pushed to 10.1.x, thanks!
Comment #15
catch