Merge the build and lint stages in core MR pipelines

Yeah this came from how we test on circle ci where spin up is faster, agree on current gitlab setup it's hurting us in overall resection time

Only realised this after working on 📌 Try to store the phpstan result cache as an artifact Active and seeing just how much time we were spending on spinning up vs doing things. With the combination of the two issues, the newly combined lint stage finishes in around a minute. Once we add cspell/phpcs/eslint cache support, it should be consistently under a minute hopefully.

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.

Just a straightforward rebase.

However I noticed since we added when: manual to the performance job, the job is blocked - needs to allow fail too it looks like.

Latest pipeline on the MR finished in 6 minutes and 52 seconds: https://git.drupalcode.org/project/drupal/-/pipelines/233855

This will also help the performance test run finish quicker. At the moment we're building composer and yarn to use the cache in performance tests, but it's much quicker to just run performance install in the actual test job before running the tests. Should save ~90s on those jobs.

Since this takes a full minute off every core MR pipeline, bumping to major.

Combining this with some other changes, was able to get the minimum time for a full MR pipeline run down to 5m37s https://git.drupalcode.org/project/drupal/-/pipelines/234735

The nightwatch job failed, not sure if fluke or bad, and can't rerun since MR was created by a core committer.

Shouldn't affect the nightwatch test at all but re-ran it just in case.

Thanks, tests are now green, as expected.
Code changes make sense.

RTBC for me.

nod_ → closed merge request !8903

Committed 3c4f80a and pushed to 11.0.x. Thanks!
Committed 3c4f80a and pushed to 11.0.x. Thanks!

Doesn't cherry pick to 10.4.x, need a new MR for it if we want to backport that

OK the commit conflicts are because we haven't done 📌 Resync .gitlab-ci.yml and .gitignore following Yarn 4 in 11.x Needs review yet. Put up an MR there. Once that's in, this should be a clean(er) cherry-pick.

Double checked the performance pipeline on 11.x and it's down to 8m30 now with the combination of this and 📌 Consolidate Umami performance tests Fixed , was previously closer to 13 minutes.

https://git.drupalcode.org/project/drupal/-/pipelines/235402

Still an issue with the cherry pick, but not too bad

I think 10.4.x-dev is the correct version for this now.

And as was said in #21 📌 Merge the build and lint stages in core MR pipelines Downport , lets postpone this on 📌 Resync .gitlab-ci.yml and .gitignore following Yarn 4 in 11.x Needs review to make our lives easier.

Backport looks good.

Opened an issue for gitlab_templates since we might see a similar improvement there 📌 Consider merging the build and validate stages Active .

adding back the -s for yarn 1 that got squeezed from https://git.drupalcode.org/project/drupal/-/commit/19c608d552a3bbedc554a...

Committed and pushed 963de90958 to 10.4.x and d170a1e09d to 10.3.x. Thanks!

nod_ → closed merge request !8960

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

Thanks for 📌 Consider merging the build and validate stages Active ! 🙏