Commit ebb5e2d7 authored by Mike Jang's avatar Mike Jang

Merge branch 'compliance-pipeline-config-documentation' into 'master'

Enable compliance pipeline configuration by default

See merge request gitlab-org/gitlab!58826
parents 5b45cd0b d27dba64
......@@ -65,6 +65,71 @@ can now create their own.
New compliance framework labels can be created and updated using GraphQL.
#### Compliance pipeline configuration **(ULTIMATE)**
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3156) in GitLab 13.9.
> - [Deployed behind a feature flag](../../feature_flags.md).
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
> - Enabled on GitLab.com.
> - Recommended for production use.
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
Group owners can use the compliance pipeline configuration to define compliance requirements
such as scans or tests, and enforce them in individual projects.
The [custom compliance framework](#custom-compliance-frameworks) feature allows group owners to specify the location
of a compliance pipeline configuration stored and managed in a dedicated project, distinct from a developer's project.
When you set up the compliance pipeline configuration field, use the
`file@group/project` format. For example, you can configure
`.compliance-gitlab-ci.yml@compliance-group/compliance-project`.
This field is inherited by projects where the compliance framework label is applied. The result
forces the project to run the compliance configurations.
When a project with a custom label executes a pipeline, it begins by evaluating the compliance pipeline configuration.
The custom pipeline configuration can then execute any included individual project configuration.
The user running the pipeline in the project should at least have Reporter access to the compliance project.
Example `.compliance-gitlab-ci.yml`
```yaml
stages: # Allows compliance team to control the ordering and interweaving of stages/jobs
- pre-compliance
- build
- test
- pre-deploy-compliance
- deploy
- post-compliance
variables: # can be overriden by a developer's local .gitlab-ci.yml
FOO: sast
sast: # none of these attributes can be overriden by a developer's local .gitlab-ci.yml
variables:
FOO: sast
stage: pre-compliance
script:
- echo "running $FOO"
sanity check:
stage: pre-deploy-compliance
script:
- echo "running $FOO"
audit trail:
stage: post-compliance
script:
- echo "running $FOO"
include: # Execute individual project's configuration
project: '$CI_PROJECT_PATH'
file: '$CI_PROJECT_CONFIG_PATH'
```
### Sharing and permissions
For your repository, you can set up features such as public access, repository features,
......
......@@ -11,7 +11,7 @@ module ComplianceManagement
condition(:group_level_compliance_pipeline_enabled) do
@subject.namespace.feature_available?(:evaluate_group_level_compliance_pipeline) &&
Feature.enabled?(:ff_evaluate_group_level_compliance_pipeline, @subject.namespace)
Feature.enabled?(:ff_evaluate_group_level_compliance_pipeline, @subject.namespace, default_enabled: :yaml)
end
rule { can?(:owner_access) & custom_compliance_frameworks_enabled }.policy do
......
---
title: Enable compliance pipeline configuration by default
merge_request: 58826
author:
type: added
......@@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/300324
milestone: '13.9'
type: development
group: group::compliance
default_enabled: false
default_enabled: true
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment