Make 'danger-review' a blocking job for all 'test' jobs
What does this MR do?
This creates a new precheck
stage which contains:
danger-review
docs lint
lint-ci-gitlab
which are fast pre-checks jobs. danger-review
is special as it acts as pre-check that "fail fast" a merge request to ensure we don't run more expensive jobs when we know after a few minutes that the whole pipeline won't pass anyway.
Note that most prepare
jobs start immediately so that the pipeline duration isn't impacted by the duration of danger-review
. That way, in the cases where danger-review
fails, some jobs run for nothing, but in the case danger-review
passes, pipelines' duration shouldn't be different than today:
Benefits
- This saves a lot of money by not running expensive jobs when we can quickly know that the pipeline won't pass. This is very important and in line with &1853.
- This gives a quicker feedback (approximately 25 minutes since
gitlab:assets:compile pull-cache
starts immediately) to engineers when their MR fails any Danger checks.
Drawbacks
- Some people would argue that when their MR isn't "ready to be merged", they'd prefer to have the pipeline run so that they can gather all the failures in one go.
Examples
Short circuited pipeline: https://gitlab.com/gitlab-org/gitlab/pipelines/125774666
Passing pipeline: TBD
Does this MR meet the acceptance criteria?
Conformity
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Separation of EE specific content
Closes #119110 (closed).
Edited by Rémy Coutable