Add latest changes from gitlab-org/gitlab@master

26 files changed, 492 insertions, 176 deletions

diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION
index 35310f489d4..76e52a1d82b 100644
--- a/GITALY_SERVER_VERSION
+++ b/GITALY_SERVER_VERSION
@@ -1 +1 @@
-7055518ce76486791c3450a8a47b673891b6e2d6
+501a7a9b19eb80ec039caeb8019cab7a8cfcbb44
diff --git a/app/assets/javascripts/cycle_analytics/components/stage_table.vue b/app/assets/javascripts/cycle_analytics/components/stage_table.vue
index 3e457079aa3..8f7a3f99bab 100644
--- a/app/assets/javascripts/cycle_analytics/components/stage_table.vue
+++ b/app/assets/javascripts/cycle_analytics/components/stage_table.vue
@@ -32,6 +32,9 @@ const WORKFLOW_COLUMN_TITLES = {
   mergeRequests: { ...DEFAULT_WORKFLOW_TITLE_PROPERTIES, label: __('Merge requests') },
 };
 
+const fullProjectPath = ({ namespaceFullPath = '', projectPath }) =>
+  namespaceFullPath.split('/').length > 1 ? `${namespaceFullPath}/${projectPath}` : projectPath;
+
 export default {
   name: 'StageTable',
   components: {
@@ -149,8 +152,10 @@ export default {
     isMrLink(url = '') {
       return url.includes('/merge_request');
     },
-    itemId({ iid, projectPath }, separator = '#') {
-      const prefix = this.includeProjectName ? projectPath : '';
+    itemId({ iid, projectPath, namespaceFullPath = '' }, separator = '#') {
+      const prefix = this.includeProjectName
+        ? fullProjectPath({ namespaceFullPath, projectPath })
+        : '';
       return `${prefix}${separator}${iid}`;
     },
     itemDisplayName(item) {
diff --git a/app/serializers/analytics_build_entity.rb b/app/serializers/analytics_build_entity.rb
index 5beb945257f..169df94ad7b 100644
--- a/app/serializers/analytics_build_entity.rb
+++ b/app/serializers/analytics_build_entity.rb
@@ -13,6 +13,10 @@ class AnalyticsBuildEntity < Grape::Entity
     build.project.path
   end
 
+  expose :namespace_full_path do |build|
+    build.project.namespace.full_path
+  end
+
   expose :started_at, as: :date do |build|
     interval_in_words(build[:started_at])
   end
diff --git a/app/serializers/analytics_issue_entity.rb b/app/serializers/analytics_issue_entity.rb
index b3244740ae1..a0d6d120a48 100644
--- a/app/serializers/analytics_issue_entity.rb
+++ b/app/serializers/analytics_issue_entity.rb
@@ -10,6 +10,10 @@ class AnalyticsIssueEntity < Grape::Entity
     object[:project_path]
   end
 
+  expose :namespace_full_path do |object|
+    object[:namespace_path]
+  end
+
   expose :iid do |object|
     object[:iid].to_s
   end
diff --git a/app/views/projects/_merge_request_merge_checks_settings.html.haml b/app/views/projects/_merge_request_merge_checks_settings.html.haml
index fbc58283cbf..6b25c5ddaef 100644
--- a/app/views/projects/_merge_request_merge_checks_settings.html.haml
+++ b/app/views/projects/_merge_request_merge_checks_settings.html.haml
@@ -8,7 +8,7 @@
     = form.label :only_allow_merge_if_pipeline_succeeds, class: 'form-check-label' do
       = s_('ProjectSettings|Pipelines must succeed')
       .text-secondary
-        - configuring_pipelines_for_merge_requests_help_link_url = help_page_path('ci/pipelines/merge_request_pipelines.md', anchor: 'configure-pipelines-for-merge-requests')
+        - configuring_pipelines_for_merge_requests_help_link_url = help_page_path('ci/pipelines/merge_request_pipelines.md', anchor: 'prerequisites')
         - configuring_pipelines_for_merge_requests_help_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: configuring_pipelines_for_merge_requests_help_link_url }
         = s_('ProjectSettings|To enable this feature, configure pipelines. %{link_start}How to configure pipelines for merge requests?%{link_end}').html_safe % { link_start: configuring_pipelines_for_merge_requests_help_link_start, link_end: '</a>'.html_safe }
   .form-check.mb-2
diff --git a/app/views/projects/pipelines/show.html.haml b/app/views/projects/pipelines/show.html.haml
index ac5d34bfd44..d654d0e04d7 100644
--- a/app/views/projects/pipelines/show.html.haml
+++ b/app/views/projects/pipelines/show.html.haml
@@ -1,3 +1,4 @@
+- @force_fluid_layout = true
 - add_to_breadcrumbs _('Pipelines'), project_pipelines_path(@project)
 - breadcrumb_title "##{@pipeline.id}"
 - page_title _('Pipeline')
diff --git a/config/feature_flags/development/sandboxed_mermaid.yml b/config/feature_flags/development/sandboxed_mermaid.yml
index a008a9fad38..434cd4055d8 100644
--- a/config/feature_flags/development/sandboxed_mermaid.yml
+++ b/config/feature_flags/development/sandboxed_mermaid.yml
@@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/349755
 milestone: '14.7'
 type: development
 group: group::analyzer frontend
-default_enabled: false
+default_enabled: true
diff --git a/data/deprecations/14.8-deprecate-artifacts-keyword.yml b/data/deprecations/14-7-deprecate-artifacts-keyword.yml
index 4d8a8ed283b..cbd1a6d41e5 100644
--- a/data/deprecations/14.8-deprecate-artifacts-keyword.yml
+++ b/data/deprecations/14-7-deprecate-artifacts-keyword.yml
@@ -1,8 +1,8 @@
 - name: "Removal of `artifacts:report:cobertura` keyword"
-  announcement_milestone: "14.8"
-  announcement_date: "2022-02-22"
+  announcement_milestone: "14.7"
+  announcement_date: "2022-01-22"
   removal_milestone: "15.0"
-  removal_date: "2022-06-22"
+  removal_date: "2022-05-22"
   breaking_change: false
   body: |
      Currently, test coverage visualizations in GitLab only support Cobertura reports. Starting 15.0, the
diff --git a/data/deprecations/14-7-deprecate-godep-support-in-license-compliance.yml b/data/deprecations/14-7-deprecate-godep-support-in-license-compliance.yml
index 5c6ea1b71f1..cf986341884 100644
--- a/data/deprecations/14-7-deprecate-godep-support-in-license-compliance.yml
+++ b/data/deprecations/14-7-deprecate-godep-support-in-license-compliance.yml
@@ -2,7 +2,7 @@
   announcement_milestone: "14.7" # The milestone when this feature was first announced as deprecated.
   announcement_date: "2022-01-22" # The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
   removal_milestone: "15.0" # The milestone when this feature is planned to be removed
-  removal_date: "2022-06-22" # This should almost always be the 22nd of a month (YYYY-MM-22), the date of the milestone release when this feature is planned to be removed.
+  removal_date: "2022-05-22" # This should almost always be the 22nd of a month (YYYY-MM-22), the date of the milestone release when this feature is planned to be removed.
   body: | # Do not modify this line, instead modify the lines below.
     The Godep dependency manager for Golang was deprecated in 2020 by Go and
     has been replaced with Go modules.
diff --git a/data/deprecations/14-7-deprecate-static-site-editor.yml b/data/deprecations/14-7-deprecate-static-site-editor.yml
new file mode 100644
index 00000000000..d8acfbf8ab3
--- /dev/null
+++ b/data/deprecations/14-7-deprecate-static-site-editor.yml
@@ -0,0 +1,14 @@
+- name: "Removal of Static Site Editor" # The name of the feature to be deprecated
+  announcement_milestone: "14.7" # The milestone when this feature was first announced as deprecated.
+  announcement_date: "2022-01-22" # The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
+  removal_milestone: "15.0" # The milestone when this feature is planned to be removed
+  removal_date: "2022-05-22" # This should almost always be the 22nd of a month (YYYY-MM-22), the date of the milestone release when this feature is planned to be removed.
+  body: | # Do not modify this line, instead modify the lines below.
+    The Static Site Editor will no longer be available starting in GitLab 15.0. Improvements to the Markdown editing experience across GitLab will deliver smiliar benefit but with a wider reach. Incoming requests to the Static Site Editor will be redirected to the Web IDE. Current users of the Static Site Editor can view the [documentation](https://docs.gitlab.com/ee/user/project/static_site_editor/) for more information, including how to remove the configuration files from existing projects.
+# The following items are not published on the docs page, but may be used in the future.
+  stage: Create # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
+  tiers: [Free, Premium, Ultimate] # (optional - may be required in the future) An array of tiers that the feature is available in currently.  e.g., [Free, Silver, Gold, Core, Premium, Ultimate]
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/347137 # (optional) This is a link to the deprecation issue in GitLab
+  documentation_url: https://docs.gitlab.com/ee/user/project/static_site_editor/ # (optional) This is a link to the current documentation page
+  image_url: # (optional) This is a link to a thumbnail image depicting the feature
+  video_url: # (optional) Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
diff --git a/data/deprecations/14-7-pseudonymizer.yml b/data/deprecations/14-7-pseudonymizer.yml
index 80eecd91cc3..34aecb55bd7 100644
--- a/data/deprecations/14-7-pseudonymizer.yml
+++ b/data/deprecations/14-7-pseudonymizer.yml
@@ -2,7 +2,7 @@
   announcement_milestone: "14.7" # The milestone when this feature was first announced as deprecated.
   announcement_date: "2021-01-22" # The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
   removal_milestone: "15.0" # The milestone when this feature is planned to be removed
-  removal_date: "2021-06-22" # This should almost always be the 22nd of a month (YYYY-MM-22), the date of the milestone release when this feature is planned to be removed.
+  removal_date: "2021-05-22" # This should almost always be the 22nd of a month (YYYY-MM-22), the date of the milestone release when this feature is planned to be removed.
   body: | # Do not modify this line, instead modify the lines below.
     The Pseudonymizer feature is generally unused,
     can cause production issues with large databases,
diff --git a/doc/ci/pipelines/img/pipeline-fork_v13_7.png b/doc/ci/pipelines/img/pipeline_fork_v13_7.png
index eb44290aa66..eb44290aa66 100644
--- a/doc/ci/pipelines/img/pipeline-fork_v13_7.png
+++ b/doc/ci/pipelines/img/pipeline_fork_v13_7.png
diff --git a/doc/ci/pipelines/merge_request_pipelines.md b/doc/ci/pipelines/merge_request_pipelines.md
index 370cdafa610..4d7ebc09e6f 100644
--- a/doc/ci/pipelines/merge_request_pipelines.md
+++ b/doc/ci/pipelines/merge_request_pipelines.md
@@ -4,210 +4,195 @@ group: Pipeline Execution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Pipelines for merge requests **(FREE)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/15310) in GitLab 11.6.
 
-In a [basic configuration](pipeline_architectures.md#basic-pipelines), GitLab runs a pipeline each time
-changes are pushed to a branch.
+# Pipelines for merge requests **(FREE)**
 
-If you want the pipeline to run jobs **only** on commits associated with a merge request,
-you can use *pipelines for merge requests*.
+You can configure your [pipeline](index.md) to run every time you commit changes to a branch.
+This type of pipeline is called a *branch pipeline*.
 
-These pipelines are labeled as `detached` in the UI, and they do not have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
-Otherwise, these pipelines are the same as other pipelines.
+Alternatively, you can configure your pipeline to run every time you make changes to the
+source branch for a merge request. This type of pipeline is called a *pipeline for merge requests*.
 
-Pipelines for merge requests can run when you:
+Branch pipelines:
 
-- Create a new merge request.
-- Commit changes to the source branch for the merge request.
-- Select the **Run pipeline** button from the **Pipelines** tab in the merge request.
+- Run when you push a new commit to a branch.
+- Are the default type of pipeline.
+- Have access to [some predefined variables](../variables/predefined_variables.md).
+- Have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
 
-If you use this feature with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md),
-pipelines for merge requests take precedence over other pipelines.
+Pipelines for merge requests:
 
-## Prerequisites
+- Run when you:
+  - Create a new merge request.
+  - Push a new commit to the source branch for a merge request.
+  - Select **Run pipeline** from the **Pipelines** tab in a merge request. This option
+    is only available when pipelines for merge requests are configured for the pipeline.
+- Do not run by default. The jobs in the CI/CD configuration file [must be configured](#prerequisites)
+  to run in pipelines for merge request.
+- Have access to [more predefined variables](#available-predefined-variables).
+- Do not have access to [protected variables](../variables/index.md#protect-a-cicd-variable).
 
-To enable pipelines for merge requests:
+Both of these types of pipelines can appear on the **Pipelines** tab of a merge request.
 
-- Your repository must be a GitLab repository, not an
-  [external repository](../ci_cd_for_external_repos/index.md).
-- You must have the Developer [role](../../user/permissions.md)
-  to run a pipeline for merge requests.
+## Types of pipelines for merge requests
 
-## Configure pipelines for merge requests
+The three types of pipelines for merge requests are:
 
-To configure pipelines for merge requests, you must configure your [CI/CD configuration file](../yaml/index.md).
-To do this, you can use [`rules`](#use-rules-to-run-pipelines-for-merge-requests) or [`only/except`](#use-only-or-except-to-run-pipelines-for-merge-requests).
+- Pipelines for merge requests, which run on the changes in the merge request's
+  source branch. These pipelines display a `detached` label to indicate that the
+  pipeline ran only on the contents of the source branch, ignoring the target branch.
+- [Pipelines for merged results](pipelines_for_merged_results.md), which run on
+  the result of combining the source branch's changes with the target branch.
+- [Merge trains](merge_trains.md), which run when merging multiple merge requests
+  at the same time. The changes from each merge request are combined into the
+  target branch with the changes in the earlier enqueued merge requests, to ensure
+  they all work together.
 
-### Use `rules` to run pipelines for merge requests
+## Prerequisites
 
-GitLab recommends that you use the `rules` keyword, which is available in
-[`workflow:rules` templates](../yaml/workflow.md#workflowrules-templates).
+To use pipelines for merge requests:
 
-### Use `only` or `except` to run pipelines for merge requests
+- Your project's [CI/CD configuration file](../yaml/index.md) must be configured with
+  jobs that run in pipelines for merge requests. To do this, you can use:
+  - [`rules`](#use-rules-to-add-jobs).
+  - [`only/except`](#use-only-to-add-jobs).
+- You must have at least the Developer [role](../../user/permissions.md) in the
+  source project to run a pipeline for merge requests.
+- Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md).
 
-You can use the `only/except` keywords. However, with this method, you must specify `only: - merge_requests` for each job.
+## Use `rules` to add jobs
 
-In the following example, the pipeline contains a `test` job that is configured to run on merge requests.
-The `build` and `deploy` jobs don't have the `only: - merge_requests` keyword,
-so they don't run on merge requests.
+You can use the [`rules`](../yaml/index.md#rules) keyword to configure jobs to run in
+pipelines for merge requests. For example:
 
 ```yaml
-build:
-  stage: build
-  script: ./build
-  only:
-    - main
-
-test:
-  stage: test
-  script: ./test
-  only:
-    - merge_requests
-
-deploy:
-  stage: deploy
-  script: ./deploy
-  only:
-    - main
+job1:
+  script:
+    - echo "This job runs in pipelines for merge requests"
+  rules:
+    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
 ```
 
-#### Exclude specific jobs
-
-When you use `only: [merge_requests]`, only jobs with
-that keyword are run in the context of a merge request. No other jobs run.
-
-However, you can invert this behavior and have all of your jobs run except
-for one or two. For example, you might have a pipeline with jobs `A`, `B`, and `C`, and you want:
-
-- All pipelines to always run `A` and `B`.
-- `C` to run only for merge requests.
-
-To achieve this outcome, configure your `.gitlab-ci.yml` file as follows:
+You can also use the [`workflow: rules`](../yaml/index.md#workflowrules) keyword
+to configure the entire pipeline to run in pipelines for merge requests. For example:
 
 ```yaml
-.only-default: &only-default
-  only:
-    - main
-    - merge_requests
-    - tags
+workflow:
+  rules:
+    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
 
-A:
-  <<: *only-default
+job1:
   script:
-    - ...
+    - echo "This job runs in pipelines for merge requests"
 
-B:
-  <<: *only-default
+job2:
   script:
-    - ...
-
-C:
-  script:
-    - ...
-  only:
-    - merge_requests
+    - echo "This job also runs in pipelines for merge requests"
 ```
 
-- `A` and `B` always run, because they get the `only` rule to execute in all cases.
-- `C` only runs for merge requests. It doesn't run for any pipeline
-  except a merge request pipeline.
-
-In this example, you don't have to add the `only` rule to all of your jobs to make
-them always run. You can use this format to set up a Review App, which helps to
-save resources.
+## Use `only` to add jobs
 
-#### Exclude specific branches
-
-Branch refs use this format: `refs/heads/my-feature-branch`.
-Merge request refs use this format: `refs/merge-requests/:iid/head`.
-
-Because of this difference, the following configuration does not work as expected:
-
-```yaml
-# Does not exclude a branch named "docs-my-fix"!
-test:
-  only: [merge_requests]
-  except: [/^docs-/]
-```
-
-Instead, use the
-[`$CI_COMMIT_REF_NAME` predefined environment
-variable](../variables/predefined_variables.md) in
-combination with
-[`only:variables`](../yaml/index.md#onlyvariables--exceptvariables) to
-accomplish this behavior:
+You can use the [`only`](../yaml/index.md#onlyrefs--exceptrefs) keyword with `merge_requests`
+to configure jobs to run in pipelines for merge requests.
 
 ```yaml
-test:
-  only: [merge_requests]
-  except:
-    variables:
-      - $CI_COMMIT_REF_NAME =~ /^docs-/
+job1:
+  script:
+    - echo "This job runs in pipelines for merge requests"
+  only:
+    - merge_requests
 ```
 
-## Run pipelines in the parent project for merge requests from a forked project **(PREMIUM)**
+## Use with forked projects
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217451) in GitLab 13.3.
 > - [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
 
-By default, external contributors who work in forks can't create pipelines in the
-parent project. When a merge request that comes from a fork triggers a pipeline:
+External contributors who work in forks can't create pipelines in the parent project.
 
-- The pipeline is created and runs in the fork (source) project, not the parent (target) project.
-- The pipeline uses the fork project's CI/CD configuration and resources.
+A merge request from a fork that is submitted to the parent project triggers a
+pipeline that:
 
-If a pipeline runs in a fork, a **fork** badge appears for the pipeline in the merge request.
+- Is created and runs in the fork (source) project, not the parent (target) project.
+- Uses the fork project's CI/CD configuration, resources, and project CI/CD variables.
 
-![Pipeline ran in fork](img/pipeline-fork_v13_7.png)
+Pipelines for forks display with the **fork** badge in the parent project:
 
-Sometimes parent project members want the pipeline to run in the parent
-project. They may want to ensure that the post-merge pipeline passes in the parent project.
-For example, a fork project could try to use a corrupted runner that doesn't execute
-test scripts properly, but reports a passed pipeline. Reviewers in the parent project
-could mistakenly trust the merge request because it passed a faked pipeline.
+![Pipeline ran in fork](img/pipeline_fork_v13_7.png)
 
-Parent project members with at least the [Developer role](../../user/permissions.md)
-can create pipelines in the parent project for merge requests
-from a forked project. In the merge request, go to the **Pipelines** tab and select
-**Run pipeline**.
+### Run pipelines in the parent project **(PREMIUM)**
+
+Project members in the parent project can choose to run a pipeline for merge requests
+for a merge request submitted from a fork project. This pipeline:
+
+- Is created and runs in the parent (target) project, not the fork (source) project.
+- Uses the CI/CD configuration present in the fork project's branch
+- Uses the parent project's CI/CD configuration, resources, and project CI/CD variables.
+- Uses the permissions of the parent project member that triggers the pipeline.
+
+Run pipelines in fork project MRs to ensure that the post-merge pipeline passes in
+the parent project. Additionally, if you do not trust the fork project's runner,
+running the pipeline in the parent project uses the parent project's trusted runners.
 
 WARNING:
 Fork merge requests can contain malicious code that tries to steal secrets in the
-parent project when the pipeline runs, even before merge. As a reviewer, you must carefully
+parent project when the pipeline runs, even before merge. As a reviewer, carefully
 check the changes in the merge request before triggering the pipeline. GitLab shows
 a warning that you must accept before you can trigger the pipeline.
 
-## Predefined variables available for pipelines for merge requests
+Parent project members with at least the [Developer role](../../user/permissions.md)
+can create pipelines in the parent project for merge requests from a forked project:
 
-When you use pipelines for merge requests, [additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines) are available to the CI/CD jobs.
-These variables contain information from the associated merge request, so that you can
-integrate your job with the [GitLab Merge Request API](../../api/merge_requests.md).
+1. In the merge request, go to the **Pipelines** tab.
+1. Select **Run pipeline**. You must accept the warning, or the pipeline does not run.
 
-## Troubleshooting
+## Available predefined variables
 
-### Two pipelines created when pushing to a merge request
+When you use pipelines for merge requests, you can use:
+
+- All the same [predefined variables](../variables/predefined_variables.md) that are
+  available in branch pipelines.
+- [Additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
+  available only to jobs in pipelines for merge requests. These variables contain
+  information from the associated merge request, which can be when calling the
+  [GitLab Merge Request API endpoint](../../api/merge_requests.md) from a job.
+
+## Troubleshooting
 
-If you are experiencing duplicated pipelines when using `rules`, take a look at
-the [important differences between `rules` and `only`/`except`](../jobs/job_control.md#avoid-duplicate-pipelines),
-which helps you get your starting configuration correct.
+### Two pipelines when pushing to a branch
 
-If you are seeing two pipelines when using `only/except`, please see the caveats
-related to using `only/except` above (or, consider moving to `rules`).
+If you get duplicate pipelines in merge requests, your pipeline might be configured
+to run for both branches and merge requests at the same time. Adjust your pipeline
+configuration to [avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
 
 In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201845),
-you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines).
+you can add `workflow:rules` to [switch from branch pipelines to pipelines for merge requests](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines).
 After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
 
-### Two pipelines created when pushing an invalid CI configuration file
+### Two pipelines when pushing an invalid CI/CD configuration file
+
+If you push an invalid CI/CD configuration to a merge request's branch, two failed
+pipelines appear in the pipelines tab. One pipeline is a failed branch pipeline,
+the other is a failed pipeline for merge requests.
+
+When the configuration syntax is fixed, no further failed pipelines should appear.
+To find and fix the configuration problem, you can use:
+
+- The [pipeline editor](../pipeline_editor/index.md).
+- The [CI lint tool](../lint.md).
+
+### The merge request's pipeline is marked as failed but the latest pipeline succeeded
+
+It's possible to have both branch pipelines and pipelines for merge requests in the
+**Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines),
+or [by accident](#two-pipelines-when-pushing-to-a-branch).
 
-Pushing to a branch with an invalid CI configuration file can trigger
-the creation of two types of failed pipelines. One pipeline is a failed merge request
-pipeline, and the other is a failed branch pipeline, but both are caused by the same
-invalid configuration.
+If both types of pipelines are in one merge request, the merge request's pipeline
+is not considered successful if:
 
-## Related topics
+- The branch pipeline succeeds.
+- The pipeline for merge request fails.
 
-- [Pipelines for merged results](pipelines_for_merged_results.md).
-- [Merge trains](merge_trains.md).
+When using the [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
+feature and both pipelines types are present, the pipelines for merge requests are checked,
+not the branch pipelines.
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index eb5314f4a23..d47cbf5f47c 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -78,7 +78,7 @@ To enable merge trains:
 To enable merge trains for your project:
 
 1. If you are on a self-managed GitLab instance, ensure the [feature flag](#merge-trains-feature-flag) is set correctly.
-1. [Configure your CI/CD configuration file](merge_request_pipelines.md#configure-pipelines-for-merge-requests)
+1. [Configure your CI/CD configuration file](merge_request_pipelines.md#prerequisites)
    so that the pipeline or individual jobs run for merge requests.
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > General**.
diff --git a/doc/ci/pipelines/pipelines_for_merged_results.md b/doc/ci/pipelines/pipelines_for_merged_results.md
index b90e1476d73..91a49a48882 100644
--- a/doc/ci/pipelines/pipelines_for_merged_results.md
+++ b/doc/ci/pipelines/pipelines_for_merged_results.md
@@ -55,7 +55,7 @@ To enable pipelines for merge results:
 
 To enable pipelines for merged results for your project:
 
-1. [Configure your CI/CD configuration file](merge_request_pipelines.md#configure-pipelines-for-merge-requests)
+1. [Configure your CI/CD configuration file](merge_request_pipelines.md#prerequisites)
    so that the pipeline or individual jobs run for merge requests.
 1. Visit your project's **Settings > General** and expand **Merge requests**.
 1. Check **Enable merged results pipelines**.
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index 1ec264a87cf..7ce58b015ca 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -81,7 +81,7 @@ to execute scripts. Each shell has its own set of reserved variable names.
 Make sure each variable is defined for the [scope you want to use it in](where_variables_can_be_used.md).
 
 By default, pipelines from forked projects can't access CI/CD variables in the parent project.
-If you [run a merge request pipeline in the parent project for a merge request from a fork](../pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project),
+If you [run a merge request pipeline in the parent project for a merge request from a fork](../pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project),
 all variables become available to the pipeline.
 
 ### Create a custom CI/CD variable in the `.gitlab-ci.yml` file
@@ -394,7 +394,7 @@ runs on a [protected branch](../../user/project/protected_branches.md) or
 
 Review all merge requests that introduce changes to the `.gitlab-ci.yml` file before you:
 
-- [Run a pipeline in the parent project for a merge request submitted from a forked project](../pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project).
+- [Run a pipeline in the parent project for a merge request submitted from a forked project](../pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project).
 - Merge the changes.
 
 The following example shows malicious code in a `.gitlab-ci.yml` file:
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 588304cd1ad..e7edffec717 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -415,6 +415,7 @@ and the pipeline is for either:
 - You can use the [`workflow:rules` templates](workflow.md#workflowrules-templates) to import
   a preconfigured `workflow: rules` entry.
 - [Common `if` clauses for `workflow:rules`](workflow.md#common-if-clauses-for-workflowrules).
+- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `workflow:rules:variables`
 
@@ -3079,6 +3080,7 @@ job:
 
 - [Common `if` expressions for `rules`](../jobs/job_control.md#common-if-clauses-for-rules).
 - [Avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines).
+- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs).
 
 #### `rules:changes`
 
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 3ab5151e05c..1ed510c6ad7 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -501,7 +501,7 @@ Merge Results against the latest `main` at the time of the pipeline creation.
 
 WARNING:
 **Review all changes thoroughly for malicious code before starting a
-[Pipeline for Merged Results](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project).**
+[Pipeline for Merged Results](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project).**
 
 When reviewing merge requests added by wider community contributors:
 
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 9de063eec6f..9db1f09cf61 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -12,11 +12,11 @@ An application data backup creates an archive file that contains the database,
 all repositories and all attachments.
 
 You can only restore a backup to **exactly the same version and type (CE/EE)**
-of GitLab on which it was created. The best way to migrate your repositories
-from one server to another is through a backup and restore.
+of GitLab on which it was created. The best way to [migrate your projects
+from one server to another](#migrate-to-a-new-server) is through a backup and restore.
 
 WARNING:
-GitLab doesn't back up items that aren't stored in the file system. If you're
+GitLab doesn't back up items that aren't stored on the file system. If you're
 using [object storage](../administration/object_storage.md), be sure to enable
 backups with your object storage provider, if desired.
 
@@ -68,6 +68,7 @@ including:
 Backups do not include:
 
 - [Mattermost data](https://docs.mattermost.com/administration/config-settings.html#file-storage)
+- Redis (and thus Sidekiq jobs)
 
 WARNING:
 GitLab does not back up any configuration files (`/etc/gitlab`), TLS keys and certificates, or system
@@ -983,7 +984,7 @@ your installation is using PgBouncer, for either performance reasons or when usi
 Next, restore `/etc/gitlab/gitlab-secrets.json` if necessary,
 [as previously mentioned](#restore-prerequisites).
 
-Reconfigure, restart and check GitLab:
+Reconfigure, restart and [check](../administration/raketasks/maintenance.md#check-gitlab-configuration) GitLab:
 
 ```shell
 sudo gitlab-ctl reconfigure
@@ -999,6 +1000,14 @@ the target for the restore.
 sudo gitlab-rake gitlab:doctor:secrets
 ```
 
+For added assurance, you can perform [an integrity check on the uploaded files](../administration/raketasks/check.md#uploaded-files-integrity):
+
+```shell
+sudo gitlab-rake gitlab:artifacts:check
+sudo gitlab-rake gitlab:lfs:check
+sudo gitlab-rake gitlab:uploads:check
+```
+
 ### Restore for Docker image and GitLab Helm chart installations
 
 For GitLab installations using the Docker image or the GitLab Helm chart on a
@@ -1180,7 +1189,7 @@ has a longer discussion explaining the potential problems.
 
 To prevent writes to the Git repository data, there are two possible approaches:
 
-- Use [maintenance mode](../administration/maintenance_mode/index.md) to place GitLab in a read-only state.
+- Use [maintenance mode](../administration/maintenance_mode/index.md) **(PREMIUM SELF)** to place GitLab in a read-only state.
 - Create explicit downtime by stopping all Gitaly services before backing up the repositories:
 
   ```shell
@@ -1282,6 +1291,198 @@ sudo GITLAB_BACKUP_PGHOST=192.168.1.10 GITLAB_BACKUP_PGPORT=5432 /opt/gitlab/bin
 See the [PostgreSQL documentation](https://www.postgresql.org/docs/12/libpq-envars.html)
 for more details on what these parameters do.
 
+## Migrate to a new server
+
+<!-- some details borrowed from GitLab.com move from Azure to GCP detailed at https://gitlab.com/gitlab-com/migration/-/blob/master/.gitlab/issue_templates/failover.md -->
+
+You can use GitLab backup and restore to migrate your instance to a new server. This section outlines a typical procedure for a GitLab deployment running on a single server.
+If you're running GitLab Geo, an alternative option is [Geo disaster recovery for planned failover](../administration/geo/disaster_recovery/planned_failover.md).
+
+WARNING:
+Avoid uncoordinated data processing by both the new and old servers, where multiple
+servers could connect concurrently and process the same data. For example, when using
+[incoming email](../administration/incoming_email.md), if both GitLab instances are
+processing email at the same time, then both instances will end up missing some data.
+This type of problem can occur with other services as well, such as a
+[non-packaged database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server),
+a non-packaged Redis instance, or non-packaged Sidekiq.
+
+Prerequisites:
+
+- Some time before your migration, consider notifying your users of upcoming
+  scheduled maintenance with a [broadcast message banner](../user/admin_area/broadcast_messages.md).
+- Ensure your backups are complete and current. Create a complete system-level backup, or
+  take a snapshot of all servers involved in the migration, in case destructive commands
+  (like `rm`) are run incorrectly.
+
+### Prepare the new server
+
+To prepare the new server:
+
+1. Copy the
+   [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079)
+   from the old server to avoid man-in-the-middle attack warnings.
+1. [Install and configure GitLab](https://about.gitlab.com/install) except
+   [incoming email](../administration/incoming_email.md):
+   1. Install GitLab.
+   1. Configure by copying `/etc/gitlab` files from the old server to the new server, and update as necessary.
+      Read the
+      [Omnibus configuration backup and restore instructions](https://docs.gitlab.com/omnibus/settings/backups.html) for more detail.
+   1. If applicable, disable [incoming email](../administration/incoming_email.md).
+   1. Block new CI/CD jobs from starting upon initial startup after the backup and restore.
+      Edit `/etc/gitlab/gitlab.rb` and set the following:
+
+      ```ruby
+      nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+      ```
+
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+1. Stop GitLab to avoid any potential unnecessary and unintentional data processing:
+
+   ```shell
+   sudo gitlab-ctl stop
+   ```
+
+1. Configure the new server to allow receiving the Redis database and GitLab backup files:
+
+   ```shell
+   sudo rm -f /var/opt/gitlab/redis/dump.rdb
+   sudo chown <your-linux-username> /var/opt/gitlab/redis
+   sudo mkdir /var/opt/gitlab/backups
+   sudo chown <your-linux-username> /var/opt/gitlab/backups
+   ```
+
+### Prepare and transfer content from the old server
+
+1. Ensure you have an up-to-date system-level backup or snapshot of the old server.
+1. Enable [maintenance mode](../administration/maintenance_mode/index.md) **(PREMIUM SELF)**,
+   if supported by your GitLab edition.
+1. Block new CI/CD jobs from starting:
+   1. Edit `/etc/gitlab/gitlab.rb`, and set the following:
+
+      ```ruby
+      nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+      ```
+
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+1. Disable periodic background jobs:
+   1. On the top bar, select **Menu > Admin**.
+   1. On the left sidebar, select **Monitoring > Background Jobs**.
+   1. Under the Sidekiq dashboard, select **Cron** tab and then
+      **Disable All**.
+1. Wait for the currently running CI/CD jobs to finish, or accept that jobs that have not completed may be lost.
+   To view jobs currently running, on the left sidebar, select **Overviews > Jobs**,
+   and then select **Running**.
+1. Wait for Sidekiq jobs to finish:
+   1. On the left sidebar, select **Monitoring > Background Jobs**.
+   1. Under the Sidekiq dashboard, select **Queues** and then **Live Poll**.
+      Wait for **Busy** and **Enqueued** to drop to 0.
+      These queues contain work that has been submitted by your users;
+      shutting down before these jobs complete may cause the work to be lost.
+      Make note of the numbers shown in the Sidekiq dashboard for post-migration verification.
+1. Flush the Redis database to disk, and stop GitLab other than the services needed for migration:
+
+   ```shell
+   sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket save && sudo gitlab-ctl stop && sudo gitlab-ctl start postgresql
+   ```
+
+1. Create a GitLab backup:
+
+   ```shell
+   sudo gitlab-backup create
+   ```
+
+1. Disable the following GitLab services and prevent unintentional restarts by adding the following to the bottom of `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   alertmanager['enable'] = false
+   gitlab_exporter['enable'] = false
+   gitlab_pages['enable'] = false
+   gitlab_workhorse['enable'] = false
+   grafana['enable'] = false
+   logrotate['enable'] = false
+   gitlab_rails['incoming_email_enabled'] = false
+   nginx['enable'] = false
+   node_exporter['enable'] = false
+   postgres_exporter['enable'] = false
+   postgresql['enable'] = false
+   prometheus['enable'] = false
+   puma['enable'] = false
+   redis['enable'] = false
+   redis_exporter['enable'] = false
+   registry['enable'] = false
+   sidekiq['enable'] = false
+   ```
+
+1. Reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Verify everything is stopped, and confirm no services are running:
+
+   ```shell
+   sudo gitlab-ctl status
+   ```
+
+1. Transfer the Redis database and GitLab backups to the new server:
+
+   ```shell
+   sudo scp /var/opt/gitlab/redis/dump.rdb <your-linux-username>@new-server:/var/opt/gitlab/redis
+   sudo scp /var/opt/gitlab/backups/your-backup.tar <your-linux-username>@new-server:/var/opt/gitlab/backups
+   ```
+
+### Restore data on the new server
+
+1. Restore appropriate file system permissions:
+
+   ```shell
+   sudo chown gitlab-redis /var/opt/gitlab/redis
+   sudo chown gitlab-redis:gitlab-redis /var/opt/gitlab/redis/dump.rdb
+   sudo chown git:root /var/opt/gitlab/backups
+   sudo chown git:git /var/opt/gitlab/backups/your-backup.tar
+   ```
+
+1. [Restore the GitLab backup](#restore-gitlab).
+1. Verify that the Redis database restored correctly:
+   1. On the top bar, select **Menu > Admin**.
+   1. On the left sidebar, select **Monitoring > Background Jobs**.
+   1. Under the Sidekiq dashboard, verify that the numbers
+      match with what was shown on the old server.   
+   1. While still under the Sidekiq dashboard, select **Cron** and then **Enable All**
+      to re-enable periodic background jobs.
+1. Test that read-only operations on the GitLab instance work as expected. For example, browse through project repository files, merge requests, and issues.
+1. Disable [Maintenance Mode](../administration/maintenance_mode/index.md) **(PREMIUM SELF)**, if previously enabled.
+1. Test that the GitLab instance is working as expected.
+1. If applicable, re-enable [incoming email](../administration/incoming_email.md) and test it is working as expected.
+1. Update your DNS or load balancer to point at the new server.
+1. Unblock new CI/CD jobs from starting by removing the custom NGINX config
+   you added previously:
+
+   ```ruby
+   # The following line must be removed
+   nginx['custom_gitlab_server_config'] = "location /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"
+   ```
+
+1. Reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Remove the scheduled maintenance [broadcast message banner](../user/admin_area/broadcast_messages.md).
+
 ## Additional notes
 
 This documentation is for GitLab Community and Enterprise Edition. We back up
diff --git a/doc/subscriptions/bronze_starter.md b/doc/subscriptions/bronze_starter.md
index 695485da7f5..2c66d32f669 100644
--- a/doc/subscriptions/bronze_starter.md
+++ b/doc/subscriptions/bronze_starter.md
@@ -98,7 +98,7 @@ the tiers are no longer mentioned in GitLab documentation:
     - [Bidirectional mirroring](../user/project/repository/mirror/bidirectional.md)
     - [Mirror with Perforce Helix with Git Fusion](../user/project/repository/mirror/bidirectional.md#mirror-with-perforce-helix-with-git-fusion)
 - Runners:
-  - Run pipelines in the parent project [for merge requests from a forked project](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project)
+  - Run pipelines in the parent project [for merge requests from a forked project](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project)
   - [Shared runners CI/CD minutes](../ci/pipelines/cicd_minutes.md)
 - [Push rules](../push_rules/push_rules.md)
 - SAML for self-managed GitLab instance:
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 3fbf9ec2db4..c1e00c2f57b 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -313,7 +313,7 @@ has been replaced with Go modules.
 To reduce our maintenance cost we are deprecating License Compliance for Godep projects as of 14.7
 and will remove it in GitLab 15.0
 
-Planned removal milestone: 15.0 (2022-06-22)
+Planned removal milestone: 15.0 (2022-05-22)
 
 ### Logging in GitLab
 
@@ -335,16 +335,14 @@ can cause production issues with large databases,
 and can interfere with object storage development.
 It is now considered deprecated, and will be removed in GitLab 15.0.
 
-Planned removal milestone: 15.0 (2021-06-22)
+Planned removal milestone: 15.0 (2021-05-22)
 
-### Tracing in GitLab
+### Removal of Static Site Editor
 
-Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users can navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab is deprecated in GitLab 14.7, and scheduled for removal in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
+The Static Site Editor will no longer be available starting in GitLab 15.0. Improvements to the Markdown editing experience across GitLab will deliver smiliar benefit but with a wider reach. Incoming requests to the Static Site Editor will be redirected to the Web IDE. Current users of the Static Site Editor can view the [documentation](https://docs.gitlab.com/ee/user/project/static_site_editor/) for more information, including how to remove the configuration files from existing projects.
 
 Planned removal milestone: 15.0 (2022-05-22)
 
-## 14.8
-
 ### Removal of `artifacts:report:cobertura` keyword
 
 Currently, test coverage visualizations in GitLab only support Cobertura reports. Starting 15.0, the
@@ -352,4 +350,10 @@ Currently, test coverage visualizations in GitLab only support Cobertura reports
 [`artifacts:reports:coverage_report`](https://gitlab.com/gitlab-org/gitlab/-/issues/344533). Cobertura will be the
 only supported report file in 15.0, but this is the first step towards GitLab supporting other report types.
 
-Planned removal milestone: 15.0 (2022-06-22)
+Planned removal milestone: 15.0 (2022-05-22)
+
+### Tracing in GitLab
+
+Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users can navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab is deprecated in GitLab 14.7, and scheduled for removal in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
+
+Planned removal milestone: 15.0 (2022-05-22)
diff --git a/doc/user/project/merge_requests/fail_fast_testing.md b/doc/user/project/merge_requests/fail_fast_testing.md
index 0d87a04461b..3cb50195f5a 100644
--- a/doc/user/project/merge_requests/fail_fast_testing.md
+++ b/doc/user/project/merge_requests/fail_fast_testing.md
@@ -42,7 +42,7 @@ This template requires:
 - A project built in Rails that uses RSpec for testing.
 - CI/CD configured to:
   - Use a Docker image with Ruby available.
-  - Use [Pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md#configure-pipelines-for-merge-requests)
+  - Use [Pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md#prerequisites)
 - [Pipelines for Merged Results](../../../ci/pipelines/pipelines_for_merged_results.md#enable-pipelines-for-merged-results)
   enabled in the project settings.
 - A Docker image with Ruby available. The template uses `image: ruby:2.6` by default, but you [can override](../../../ci/yaml/includes.md#override-included-configuration-values) this.
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 73959468a49..9300c678053 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -31567,6 +31567,9 @@ msgstr ""
 msgid "SecurityConfiguration|Vulnerability details and statistics in the merge request"
 msgstr ""
 
+msgid "SecurityOrchestration| or "
+msgstr ""
+
 msgid "SecurityOrchestration|%{branches} %{plural}"
 msgstr ""
 
@@ -31654,6 +31657,9 @@ msgstr ""
 msgid "SecurityOrchestration|Policy type"
 msgstr ""
 
+msgid "SecurityOrchestration|Require %{approvals} %{plural} from %{approvers} if any of the following occur:"
+msgstr ""
+
 msgid "SecurityOrchestration|Rule"
 msgstr ""
 
@@ -31702,6 +31708,9 @@ msgstr ""
 msgid "SecurityOrchestration|Status"
 msgstr ""
 
+msgid "SecurityOrchestration|The %{scanners} %{severities} in an open merge request targeting the %{branches}."
+msgstr ""
+
 msgid "SecurityOrchestration|There was a problem creating the new security policy"
 msgstr ""
 
@@ -31720,9 +31729,51 @@ msgstr ""
 msgid "SecurityOrchestration|Update scan execution policies"
 msgstr ""
 
+msgid "SecurityOrchestration|a"
+msgstr ""
+
+msgid "SecurityOrchestration|an"
+msgstr ""
+
+msgid "SecurityOrchestration|branch"
+msgstr ""
+
+msgid "SecurityOrchestration|branches"
+msgstr ""
+
+msgid "SecurityOrchestration|members of groups"
+msgstr ""
+
+msgid "SecurityOrchestration|members of groups with ids"
+msgstr ""
+
+msgid "SecurityOrchestration|members of the group"
+msgstr ""
+
+msgid "SecurityOrchestration|members of the group with id"
+msgstr ""
+
+msgid "SecurityOrchestration|scanner finds"
+msgstr ""
+
+msgid "SecurityOrchestration|scanners find"
+msgstr ""
+
+msgid "SecurityOrchestration|user with id"
+msgstr ""
+
+msgid "SecurityOrchestration|users with ids"
+msgstr ""
+
 msgid "SecurityOrchestration|view results"
 msgstr ""
 
+msgid "SecurityOrchestration|vulnerabilities"
+msgstr ""
+
+msgid "SecurityOrchestration|vulnerability"
+msgstr ""
+
 msgid "SecurityPolicies|+%{count} more"
 msgstr ""
 
@@ -41506,6 +41557,11 @@ msgstr ""
 msgid "any-approver for the project already exists"
 msgstr ""
 
+msgid "approval"
+msgid_plural "approvals"
+msgstr[0] ""
+msgstr[1] ""
+
 msgid "approved by: "
 msgstr ""
 
diff --git a/spec/frontend/cycle_analytics/stage_table_spec.js b/spec/frontend/cycle_analytics/stage_table_spec.js
index 69de2044a8b..9605dce2668 100644
--- a/spec/frontend/cycle_analytics/stage_table_spec.js
+++ b/spec/frontend/cycle_analytics/stage_table_spec.js
@@ -198,6 +198,7 @@ describe('StageTable', () => {
   });
 
   describe('includeProjectName set', () => {
+    const fakenamespace = 'some/fake/path';
     beforeEach(() => {
       wrapper = createComponent({ includeProjectName: true });
     });
@@ -210,6 +211,37 @@ describe('StageTable', () => {
         expect(links[index]).toBe(`${ev.projectPath}#${ev.iid}`);
       });
     });
+
+    describe.each`
+      namespaceFullPath | hasFullPath
+      ${'fake'}         | ${false}
+      ${fakenamespace}  | ${true}
+    `('with a namespace', ({ namespaceFullPath, hasFullPath }) => {
+      let evs = null;
+      let links = null;
+
+      beforeEach(() => {
+        wrapper = createComponent({
+          includeProjectName: true,
+          stageEvents: issueEventItems.map((ie) => ({ ...ie, namespaceFullPath })),
+        });
+
+        evs = findStageEvents();
+        links = evs.wrappers.map((ev) => findStageEventLink(ev).text());
+      });
+
+      it(`with namespaceFullPath='${namespaceFullPath}' ${
+        hasFullPath ? 'will' : 'does not'
+      } include the namespace`, () => {
+        issueEventItems.forEach((ev, index) => {
+          if (hasFullPath) {
+            expect(links[index]).toBe(`${namespaceFullPath}/${ev.projectPath}#${ev.iid}`);
+          } else {
+            expect(links[index]).toBe(`${ev.projectPath}#${ev.iid}`);
+          }
+        });
+      });
+    });
   });
 
   describe('Pagination', () => {
diff --git a/spec/serializers/analytics_build_entity_spec.rb b/spec/serializers/analytics_build_entity_spec.rb
index b8ccc698526..b5678d91248 100644
--- a/spec/serializers/analytics_build_entity_spec.rb
+++ b/spec/serializers/analytics_build_entity_spec.rb
@@ -31,6 +31,10 @@ RSpec.describe AnalyticsBuildEntity do
       expect(subject).to include(:project_path)
     end
 
+    it 'contains the namespace full path' do
+      expect(subject).to include(:namespace_full_path)
+    end
+
     it 'does not contain sensitive information' do
       expect(subject).not_to include(/token/)
       expect(subject).not_to include(/variables/)
diff --git a/spec/serializers/analytics_issue_entity_spec.rb b/spec/serializers/analytics_issue_entity_spec.rb
index 57385471f2a..bc5cab638cd 100644
--- a/spec/serializers/analytics_issue_entity_spec.rb
+++ b/spec/serializers/analytics_issue_entity_spec.rb
@@ -36,6 +36,10 @@ RSpec.describe AnalyticsIssueEntity do
       expect(subject).to include(:project_path)
     end
 
+    it 'contains the namespace full path' do
+      expect(subject).to include(:namespace_full_path)
+    end
+
     it 'does not contain sensitive information' do
       expect(subject).not_to include(/token/)
       expect(subject).not_to include(/variables/)