Allow stage definitions in custom yaml
What does this MR do and why?
This enables stages to be defined in a security policy using custom yaml:
- It merges stages defined in security policy yaml with stages defined in project
.gitlab-ci.yaml
or default stages. - It injects
.pre
and.post
stages at the beginning and end of the stages.
Screenshots or screen recordings
How to set up and validate locally
- Upload a GitLab Ultimate license.
- Enable the feature flag:
echo "Feature.enable(:compliance_pipeline_in_policies)" | rails c
- Create a new project with a simple
.gitlab-ci.yml
file:project job: stage: build script: - echo "job defined in project CI"
- Go to Secure -> Policies -> New policy -> Scan Execution Policy.
- Go to yaml mode and paste a policy that defines custom stages:
type: scan_execution_policy name: 'custom stages' description: '' enabled: true rules: - type: pipeline branches: - '*' actions: - scan: custom ci_configuration: |- stages: - custom_stage security policy job: stage: custom_stage script: - echo "This is a security policy"
- Go back to the project -> Build -> Pipelines.
- Select Run Pipeline.
- Select Run Pipeline again.
- The pipeline should have two stages
build
andcustom_stage
.
Other things to verify
Merge stages with project CI
- Change
.gitlab-ci.yml
to include a custom stage:stages: - custom_project_stage project job: stage: custom_project_stage script: - echo "job defined in project CI"
- Commit the changes
- The latest pipeline should have
custom_stage
andcustom_project_stage
Edge stages
- Change
.gitlab-ci.yml
to include jobs for edge stages:pre job: stage: .pre script: - echo "job defined in project CI" post job: stage: .post script: - echo "job defined in project CI"
- Commit the changes.
- The latest pipeline should have the following stages in the same order:
.pre
custom_stage
.post
Rule schedules
- Go back to Secure -> Policies
- Select custom stages -> Edit policy
- Change the policy to run on a schedule:
type: scan_execution_policy name: custom stages description: '' enabled: true rules: - type: schedule cadence: 0 0 * * * branch_type: all actions: - scan: custom ci_configuration: |- stages: - custom_stage security policy job: stage: custom_stage script: - echo "This is a security policy"
- Trigger the schedule worker
echo "Security::OrchestrationPolicyRuleSchedule.update_all(next_run_at: Time.now - 1.day)\nSecurity::OrchestrationPolicyRuleScheduleWorker.new.perform" | rails c
- Go back to the project -> Build -> Pipelines.
- Select the latest pipeline. (It might take a few seconds until the rule schedule pipeline appears)
- There should only be one job on the
custom_stage
stage.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #425012 (closed)
Edited by Andy Schoenen