Problem/Motivation

The first jobs listed in gitlabci.yml run first in gitlab. This can impact the order they get allocated a pod etc. The UI is alphabetical so it only affects the running order, not anything else.

Currently phpstan tends to be the slowest linting job, and component unit tests take longer than core unit tests.

The improvement here is likely to be a 1-10 seconds at most, but it's also very easy to move a chunk of code, so development time to annual CI runtime is still going to gain many hundreds of seconds.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3560920

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:

Comments

catch created an issue. See original summary.

catch’s picture

Status: Active » Needs review
mondrake’s picture

Status: Needs review » Reviewed & tested by the community

no brainer

catch’s picture

We could potentially move the phpunit jobs before the lint jobs since they're generally faster, I don't know if that's doable with the same visual representation though. But also, can just see how this goes.

catch’s picture

StatusFileSize
new327.67 KB

You can see the ~5s spread between job start times in the 'jobs' summary.

needs-review-queue-bot’s picture

Status: Reviewed & tested by the community » Needs work
StatusFileSize
new91 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

catch’s picture

Tried some things with Functional js tests but there is some kind of fundamental constraint that splitting into more jobs and lower or higher concurrency does not help with.

The original idea of moving unit tests after lint job does help all the main test jobs start earlier still. Got at least two sub-5 minute test runs on the MR which is not very common.

catch’s picture

Title: Move gitlabci.yml jobs around » Start unit tests after lint jobs in gitlab CI
Status: Needs work » Needs review
smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

lets do it! No objections.

quietone’s picture

Yes, let's do this one. I read the comments, mr and updated credit.

needs-review-queue-bot’s picture

Status: Reviewed & tested by the community » Needs work
StatusFileSize
new91 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

catch’s picture

Status: Needs work » Reviewed & tested by the community

Rebased.

  • godotislate committed fdd25a7f on main
    task: #3560920 Start unit tests after lint jobs in gitlab CI
    
    By: catch...
godotislate’s picture

Status: Reviewed & tested by the community » Fixed

Committed fdd25a7 and pushed to main. Thanks!

Change did not apply to 11.x, so setting to Fixed unless someone wants to reopen with a backport.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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