Add latest changes from gitlab-org/gitlab@master

2 files changed, 79 insertions, 24 deletions

diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index 574d466cd53..de36cb30257 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -205,23 +205,18 @@ The keys for a schedule rule are:
 
 ## `scan` action type
 
-> - Scan Execution Policies variable precedence was [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/424028) in GitLab 16.7 [with a flag](../../../administration/feature_flags.md) named `security_policies_variables_precedence`. Enabled by default.
-> - The `custom` scan action type was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/126457) in GitLab 16.4 [with a flag](../../../administration/feature_flags.md) named `compliance_pipeline_in_policies`. On GitLab.com, this feature is not available. On self-managed GitLab, by default this feature is not available. To make it available, an administrator can [enable the feature flag](../../../administration/feature_flags.md) named `compliance_pipeline_in_policies`.
+> Scan Execution Policies variable precedence was [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/424028) in GitLab 16.6 [with a flag](../../../administration/feature_flags.md) named `security_policies_variables_precedence`. Disabled by default.
 
 This action executes the selected `scan` with additional parameters when conditions for at least one
 rule in the defined policy are met.
 
 | Field | Type | Possible values | Description |
 |-------|------|-----------------|-------------|
-| `scan` | `string` | `sast`, `sast_iac`, `dast`, `secret_detection`, `container_scanning`, `dependency_scanning`, `custom` | The action's type. |
+| `scan` | `string` | `sast`, `sast_iac`, `dast`, `secret_detection`, `container_scanning`, `dependency_scanning` | The action's type. |
 | `site_profile` | `string` | Name of the selected [DAST site profile](../dast/on-demand_scan.md#site-profile). | The DAST site profile to execute the DAST scan. This field should only be set if `scan` type is `dast`. |
 | `scanner_profile` | `string` or `null` | Name of the selected [DAST scanner profile](../dast/on-demand_scan.md#scanner-profile). | The DAST scanner profile to execute the DAST scan. This field should only be set if `scan` type is `dast`.|
 | `variables` | `object` | | A set of CI variables, supplied as an array of `key: value` pairs, to apply and enforce for the selected scan. The `key` is the variable name, with its `value` provided as a string. This parameter supports any variable that the GitLab CI job supports for the specified scan. |
 | `tags` | `array` of `string` | | A list of runner tags for the policy. The policy jobs are run by runner with the specified tags. |
-| `ci_configuration` <sup>1</sup> | `string` | | GitLab CI YAML as formatted as string. |
-| `ci_configuration_path` <sup>1</sup> | object | Object with project path and file name pointing to a CI configuration. |
-
-1. For `custom` scans, you must specify one of `ci_configuration` or `ci_configuration_path`.
 
 Note the following:
 
@@ -241,16 +236,6 @@ Note the following:
 - A container scanning scan that is configured for the `pipeline` rule type ignores the agent defined in the `agents` object. The `agents` object is only considered for `schedule` rule types.
   An agent with a name provided in the `agents` object must be created and configured for the project.
 - Variables defined in a Scan Execution Policy follow the standard [CI/CD variable precedence](../../../ci/variables/index.md#cicd-variable-precedence).
-- `custom` scans are not executed for scheduled rules.
-- Jobs variables and stages definitions from `custom` scans take precedence over the project's CI/CD configuration.
-
-### `ci_configuration_path` object
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `project` | `string` | A project namespace path. |
-| `file` | `string` | The filename of the CI/CD YAML file. |
-| `ref` | `string` (optional) | The branch name, tag name, or commit SHA. |
 
 ## Example security policies project
 
@@ -271,12 +256,6 @@ scan_execution_policy:
   - scan: dast
     scanner_profile: Scanner Profile A
     site_profile: Site Profile B
-  - scan: custom
-    ci_configuration: |-
-      test job:
-        stage: test
-        script:
-          - echo "Hello World"
 - name: Enforce DAST and secret detection scans every 10 minutes
   description: This policy enforces DAST and secret detection scans to run every 10 minutes
   enabled: true
@@ -344,3 +323,79 @@ this case, two SAST jobs run in the pipeline, one with the developer's variables
 If you want to avoid running duplicate scans, you can either remove the scans from the project's `.gitlab-ci.yml` file or disable your
 local jobs by setting `SAST_DISABLED: "true"`. Disabling jobs this way does not prevent the security jobs defined by scan execution
 policies from running.
+
+## Experimental features **(EXPERIMENT)**
+
+These experimental features have limitations:
+
+1. Enforcing pipeline execution using the pipeline execution action in projects
+   without a `.gitlab-ci.yml` is not supported.
+1. The pipeline execution action cannot be used with a scheduled trigger type.
+
+### Pipeline execution policy action
+
+> The `custom` scan action type was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/126457) in GitLab 16.4 [with a flag](../../../administration/feature_flags.md) named `compliance_pipeline_in_policies`.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available,
+an administrator can [enable the feature flag](../../../administration/feature_flags.md)
+named `compliance_pipeline_in_policies`.
+On GitLab.com, this feature is not available.
+
+The pipeline execution policy action introduces a new scan action type into
+scan execution policies for creating and enforcing custom CI in your target
+development projects.
+
+This custom scan type uses a remote CI configuration file to define the custom
+CI you want enforced. Scan execution policies then merge this file with the
+project's `.gitlab-ci.yml` to execute the compliance jobs for each project
+enforced by the policy.
+
+#### `ci_configuration_path` object
+
+| Field     | Type                | Description |
+|-----------|---------------------|-------------|
+| `project` | `string`            | A project namespace path. |
+| `file`    | `string`            | The file name of the CI/CD YAML file. |
+| `ref`     | `string` (optional) | The branch name, tag name, or commit SHA. |
+
+#### `scan` action type
+
+This action executes the selected `scan` with additional parameters when
+conditions for at least one rule in the defined policy are met.
+
+| Field                   | Type     | Possible values | Description |
+|-------------------------|----------|-----------------|-------------|
+| `scan`                  | `string` | `custom`        | The action's type. |
+| `ci_configuration`      | `string` |                 | GitLab CI YAML as formatted as string. |
+| `ci_configuration_path` | object   |                 | Object with project path and file name pointing to a CI configuration. |
+
+Note the following:
+
+- For `custom` scans, you must specify one of `ci_configuration` or `ci_configuration_path`.
+- `custom` scans are being executed for triggered rules only.
+- Jobs variables and stages definitions from `custom` scans take precedence over the project's CI/CD configuration.
+
+#### Example security policies project
+
+You can use this example in a `.gitlab/security-policies/policy.yml` file stored in a
+[security policy project](index.md#security-policy-project):
+
+```yaml
+---
+scan_execution_policy:
+- name: Create a custom scan that injects test job
+  description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
+  enabled: true
+  rules:
+  - type: pipeline
+    branches:
+    - release/*
+  actions:
+  - scan: custom
+    ci_configuration: |-
+      test job:
+        stage: test
+        script:
+          - echo "Hello World"
+```
diff --git a/doc/user/project/service_desk/configure.md b/doc/user/project/service_desk/configure.md
index 721508acb24..95c15ef42b7 100644
--- a/doc/user/project/service_desk/configure.md
+++ b/doc/user/project/service_desk/configure.md
@@ -105,7 +105,7 @@ Instance administrators can add a header, footer or additional text to the GitLa
 them to all emails sent from GitLab. If you're using a custom `thank_you.md` or `new_note.md`, to include
 this content, add `%{SYSTEM_HEADER}`, `%{SYSTEM_FOOTER}`, or `%{ADDITIONAL_TEXT}` to your templates.
 
-For more information, see [System header and footer messages](../../../administration/appearance.md#system-header-and-footer-messages) and [custom additional text](../../../administration/settings/email.md#custom-additional-text).
+For more information, see [System header and footer messages](../../../administration/appearance.md#add-system-header-and-footer-messages) and [custom additional text](../../../administration/settings/email.md#custom-additional-text).
 
 ## Use a custom template for Service Desk tickets