Problem/Motivation
PHPStan usually takes a bit longer than the other lint jobs, we can run it first.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3614490
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:
- 3614490-run-phpstan-before
changes, plain diff MR !16516
Comments
Comment #2
catchComment #4
smustgrave commentedLGTM
Comment #5
longwaveNeeds rebase due to other CI changes recently.
Comment #7
longwaveRebased and fixed the
rulessection, the change is so trivial I'm going to self-RTBC this.Comment #8
mstrelan commentedI'm assuming the display on https://git.drupalcode.org/issue/drupal-3614490/-/pipelines/919368 is alphabetical and the runners kick off in the order listed in the yaml? Looking at the "queued" time for each jobs, they match the order in the yaml:
phpstan: 2 seconds
cspell: 3 seconds
phpcs: 4 seconds
eslint: 5 seconds
Compared to another random pipeline I see:
cspell: 1 seconds
phpcs: 2 seconds
phpstan: 2 seconds
So I guess this is working as intended. With such a small margin I'm guessing the point of this is if the runners are busy we can at least get started on phpstan while waiting for others to become available, is that correct?
Comment #9
catchYeah exactly, there can be small delays from either the gitlab queues or kubernetes, since phpstan takes consistently longer we give it a potential head start, if/when everything starts at the same time then it doesn't make any difference.
We also use the same approach with test suites - at the moment build tests are the shortest so those start last (the rest constantly vary so are harder get an optimal order for).
Comment #12
mstrelan commentedCommitted and pushed e5205613c6d to main and 3ac9b048ca9 to 11.x. Thanks!
Comment #14
mstrelan commented