Inject pipeline execution stages
To give users more control over the order of stages in a pipeline execution action. To archive this, we want to introduce three new 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, it jobs can only be guaranteed to run if they are assigned to a security-policy stage. It will not be possible to create custom stages in a pipeline execution policy.
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.
Implementation plan
- Remove the ability to use the
stages
keyword in pipeline execution policies (custom scan types). - Inject the security policy stages as described above.
- Assign jobs defined in a pipeline execution policy (custom scan types) to the
.pipeline-policy-test
stage if they don't specify a stage.