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

Enable compliance pipeline configuration by default

See merge request gitlab-org/gitlab!58826

doc/user/project/settings/index.md

@@ -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,

ee/app/policies/compliance_management/framework_policy.rb

@@ -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

ee/changelogs/unreleased/compliance-pipeline-config-documentation.yml

+---
+title: Enable compliance pipeline configuration by default
+merge_request: 58826
+author:
+type: added

ee/config/feature_flags/development/ff_evaluate_group_level_compliance_pipeline.yml

@@ -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