[backend] Handle pipeline execution policy reserved stages
The new policy type we want to introduce with #452379 (closed) will inject jobs into the project CI configuration. It should not be possible to define custom stages
in pipeline execution polices to avoid conflicts with the project CI configuration. We still want to give users some control over the order of stages without interfering with project CI stages. To archive this, we want to introduce three reserved
stages that will be injected into every pipeline:
-
.pipeline-policy-pre
stage will run at the very beginning of the pipeline, before the.pre
stage. .pipeline-policy-test
stage will be injected after thetest
stage. If thetest
stage does not exist, it will be injected after thebuild
stage. If thebuild
stage does not exist, it will be injected at the beginning of the pipeline after the.pre
stage.-
.pipeline-policy-post
stage will run at the very end of the pipeline, after the.post
stage.
Jobs can be assigned to one of those stages as well as any stage that exists in the project CI. However, jobs can only be guaranteed to run if they are assigned to a security-policy stage.
The stages are reserved for security policy jobs only. It is not possible to assign jobs from a project CI to one of the reserved stages.
Our previous strategy was to give stages defined in a pipeline execution policy precedence over stages from a project CI. We worked on this in #432042 (closed) but decided that this strategy will cause confusion and will be hard to configure.
Verification steps
- Create Pipeline execution policy for a project and assign CI jobs to
.pipeline-policy-pre
and/or.pipeline-policy-post
reserved stages. - Run pipeline for the project and verify that jobs run in these stages
- Create
.gitlab-ci.yml
in the project and try to assign jobs in the reserved stages. - Verify that it's not possible