Closed (fixed)
Project:
Drupal core
Version:
10.1.x-dev
Component:
other
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
15 Sep 2023 at 08:18 UTC
Updated:
30 Sep 2023 at 15:49 UTC
Jump to comment: Most recent
Problem/Motivation
Currently linting steps are part of child pipelines. This has a few issues:
It runs linting to much if we start running against multiple configurations.
We cannot show results of codequality in the MR code #3387339: Integrate codequality reports into Gitlab
SLack thread: https://drupal.slack.com/archives/CGKLP028K/p1694703448024729
Steps to reproduce
Proposed resolution
- Move linting steps to the main job.
Remaining tasks
- Move linting steps to the main job.
- After merge finish #3387339: Integrate codequality reports into Gitlab
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3387503
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:
changes
Comments
Comment #2
bbralaPosponed on #3387055: Configure GitLabCI matrix testing
Comment #3
catchComment #4
bbralaRemove phpstan step since @longwave and @catch decided we can wait on that until we see real reason to.
Comment #5
bbralaComment #7
bbralaI've moved the lint stept to the parent pipeline. Things should be linted before we start child jobs.
There are no lint jobs in the child jobs anymore. But we do have an extra composer/yarn run now in the parent job. But i think that is a good tradeoff.
Not sure how to completely test this. Will add a new branch with errors from #3387339: Integrate codequality reports into Gitlab to proove failure.
Comment #9
bbralaAll green.
Comment #10
catchLooks great when it's not messed up by me...
Will commit soon if no further feedback by then to unblock the next steps.
Comment #13
catchCommitted/pushed to 11.x and cherry-picked to 10.1.x, thanks!
Comment #14
catchWondering what it would look like if we moved the default environment test runs into the main job too, and only used child jobs for non-default environments. It would block non-default environments on a default-environment pass, and mean the common case of an MR pipeline running against the default wouldn't need the double build step. However no idea how to structure this cleanly in the YAML, and it would have other issues like having to wait for MySQL if you're actually testing a postgres bug.