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

CommentFileSizeAuthor
#11 3398321-11.patch4.31 KBgauravvvv

Issue fork drupal-3398321

Command icon 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:

About issue forks

Comments

bbrala created an issue. See original summary.

bbrala opened merge request !5208

bbrala’s picture

bbrala
Location Netherlands
commented
Issue summary: View changes
bbrala’s picture

bbrala
Location Netherlands
commented
Status: Active » Needs work
bbrala’s picture

bbrala
Location Netherlands
commented
Status: Needs work » Needs review

catch made their first commit to this issue’s fork.

catch’s picture

catch
he/him
Primary language English
commented
Status: Needs review » Reviewed & tested by the community

I 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.

  • catch committed 9f466b66 on 10.2.x 
    Issue #3398321 by bbrala, catch: Optimize GitLab resource requests phase...

  • catch committed e6d787eb on 11.x 
    Issue #3398321 by bbrala, catch: Optimize GitLab resource requests phase...
catch’s picture

catch
he/him
Primary language English
commented
Version: 11.x-dev » 10.1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Going 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'.

gauravvvv’s picture

gauravvvv commented
StatusFileSize
new 3398321-11.patch4.31 KB

I have re-rolled the patch fro 10.1.x. please check

bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented
Status: Patch (to be ported) » Reviewed & tested by the community

Thanks @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.

  • catch committed 457663eb on 10.1.x 
    Issue #3398321 by bbrala, catch, Gauravvvv, BramDriesen: Optimize GitLab...
catch’s picture

catch
he/him
Primary language English
commented

Committed/pushed to 10.1.x, thanks!

catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

bbrala closed merge request !5208