Add latest changes from gitlab-org/gitlab@master

27 files changed, 451 insertions, 379 deletions

diff --git a/app/assets/javascripts/issues/list/components/issues_list_app.vue b/app/assets/javascripts/issues/list/components/issues_list_app.vue
index 11911adb401..a3d4bb668e2 100644
--- a/app/assets/javascripts/issues/list/components/issues_list_app.vue
+++ b/app/assets/javascripts/issues/list/components/issues_list_app.vue
@@ -24,6 +24,7 @@ import axios from '~/lib/utils/axios_utils';
 import { isPositiveInteger } from '~/lib/utils/number_utils';
 import { scrollUp } from '~/lib/utils/scroll_utils';
 import { getParameterByName, joinPaths } from '~/lib/utils/url_utility';
+import { helpPagePath } from '~/helpers/help_page_helper';
 import {
   DEFAULT_NONE_ANY,
   OPERATOR_IS_ONLY,
@@ -462,6 +463,9 @@ export default {
         page_before: this.pageParams.beforeCursor ?? undefined,
       };
     },
+    issuesHelpPagePath() {
+      return helpPagePath('user/project/issues/index');
+    },
   },
   watch: {
     $route(newValue, oldValue) {
@@ -899,7 +903,9 @@ export default {
     <template v-else-if="isSignedIn">
       <gl-empty-state :title="$options.i18n.noIssuesSignedInTitle" :svg-path="emptyStateSvgPath">
         <template #description>
-          <p>{{ $options.i18n.noIssuesSignedInDescription }}</p>
+          <gl-link :href="issuesHelpPagePath" target="_blank">{{
+            $options.i18n.noIssuesSignedInDescription
+          }}</gl-link>
           <p v-if="canCreateProjects">
             <strong>{{ $options.i18n.noGroupIssuesSignedInDescription }}</strong>
           </p>
diff --git a/app/assets/javascripts/issues/list/constants.js b/app/assets/javascripts/issues/list/constants.js
index 38fe4c33792..f5f17fa168c 100644
--- a/app/assets/javascripts/issues/list/constants.js
+++ b/app/assets/javascripts/issues/list/constants.js
@@ -41,12 +41,8 @@ export const i18n = {
   ),
   noOpenIssuesDescription: __('To keep this project going, create a new issue'),
   noOpenIssuesTitle: __('There are no open issues'),
-  noIssuesSignedInDescription: __(
-    'Issues can be bugs, tasks or ideas to be discussed. Also, issues are searchable and filterable.',
-  ),
-  noIssuesSignedInTitle: __(
-    'The Issue Tracker is the place to add things that need to be improved or solved in a project',
-  ),
+  noIssuesSignedInDescription: __('Learn more about issues.'),
+  noIssuesSignedInTitle: __('Use issues to collaborate on ideas, solve problems, and plan work'),
   noIssuesSignedOutButtonText: __('Register / Sign In'),
   noIssuesSignedOutDescription: __(
     'The Issue Tracker is the place to add things that need to be improved or solved in a project. You can register or sign in to create issues for this project.',
diff --git a/app/assets/javascripts/vue_shared/components/markdown/toolbar.vue b/app/assets/javascripts/vue_shared/components/markdown/toolbar.vue
index aa325862f06..b5640e12541 100644
--- a/app/assets/javascripts/vue_shared/components/markdown/toolbar.vue
+++ b/app/assets/javascripts/vue_shared/components/markdown/toolbar.vue
@@ -72,7 +72,7 @@ export default {
         </gl-sprintf>
       </template>
     </div>
-    <span v-if="canAttachFile" class="uploading-container">
+    <span v-if="canAttachFile" class="uploading-container gl-line-height-32">
       <span class="uploading-progress-container hide">
         <gl-icon name="paperclip" />
         <span class="attaching-file-message"></span>
diff --git a/app/assets/stylesheets/framework/markdown_area.scss b/app/assets/stylesheets/framework/markdown_area.scss
index 7522f791b8e..b623f18c4ae 100644
--- a/app/assets/stylesheets/framework/markdown_area.scss
+++ b/app/assets/stylesheets/framework/markdown_area.scss
@@ -104,7 +104,6 @@
   li.md-header-toolbar {
     margin-left: auto;
     visibility: hidden;
-    padding-bottom: $gl-padding-8;
 
     &.active {
       visibility: visible;
diff --git a/app/views/shared/_md_preview.html.haml b/app/views/shared/_md_preview.html.haml
index a49a0667d84..7314a7ddadc 100644
--- a/app/views/shared/_md_preview.html.haml
+++ b/app/views/shared/_md_preview.html.haml
@@ -11,13 +11,13 @@
   .md-header
     = gl_tabs_nav({ class: 'clearfix nav-links'}) do
       %li.md-header-tab.active
-        %button.js-md-write-button
+        %button.js-md-write-button{ class: 'gl-py-3!' }
           = _("Write")
       %li.md-header-tab
-        %button.js-md-preview-button
+        %button.js-md-preview-button{ class: 'gl-py-3!' }
           = _("Preview")
 
-      %li.md-header-toolbar.active
+      %li.md-header-toolbar.active.gl-py-2
         = render 'shared/blob/markdown_buttons', show_fullscreen_button: true
 
   .md-write-holder
diff --git a/app/views/shared/notes/_hints.html.haml b/app/views/shared/notes/_hints.html.haml
index 44740db5a00..fb000b9aab1 100644
--- a/app/views/shared/notes/_hints.html.haml
+++ b/app/views/shared/notes/_hints.html.haml
@@ -9,7 +9,7 @@
     - else
       = html_escape(s_('MarkdownToolbar|Supports %{markdownDocsLinkStart}Markdown%{markdownDocsLinkEnd}')) % { markdownDocsLinkStart: markdownLinkStart, markdownDocsLinkEnd: '</a>'.html_safe }
   - if supports_file_upload
-    %span.uploading-container
+    %span.uploading-container.gl-line-height-32
       %span.uploading-progress-container.hide
         = sprite_icon('paperclip', css_class: 'gl-icon gl-vertical-align-text-bottom')
         %span.attaching-file-message
diff --git a/doc/api/pipeline_triggers.md b/doc/api/pipeline_triggers.md
index 8db071bf811..9f3120bd5d7 100644
--- a/doc/api/pipeline_triggers.md
+++ b/doc/api/pipeline_triggers.md
@@ -155,7 +155,7 @@ or a [CI/CD job token](../ci/jobs/ci_job_token.md) for authentication.
 
 With a CI/CD job token, the [triggered pipeline is a multi-project pipeline](../ci/jobs/ci_job_token.md#trigger-a-multi-project-pipeline-by-using-a-cicd-job-token).
 The job that authenticates the request becomes associated with the upstream pipeline,
-which is visible on the [pipeline graph](../ci/pipelines/multi_project_pipelines.md#multi-project-pipeline-visualization).
+which is visible on the [pipeline graph](../ci/pipelines/downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs).
 
 If you use a trigger token in a job, the job is not associated with the upstream pipeline.
 
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 5b2e2045bdc..788061b2955 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -131,7 +131,7 @@ All users with the Maintainer role for the project have access to production sec
 that can deploy to a production environment, you can create a separate project and configure a new
 permission model that isolates the CD permissions from the original project and prevents the
 original users with the Maintainer role for the project from accessing the production secret and CD configuration. You can
-connect the CD project to your development projects by using [multi-project pipelines](../pipelines/multi_project_pipelines.md).
+connect the CD project to your development projects by using [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 
 ## Protect `.gitlab-ci.yml` from change
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index b45929fd78f..217d12e4c26 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -244,7 +244,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
 | `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests).                                            |
 | `merge_request_event`         | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
 | `parent_pipeline`             | For pipelines triggered by a [parent/child pipeline](../pipelines/parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline.                |
-| `pipeline`                    | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
+| `pipeline`                    | For [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines) created by [using the API with `CI_JOB_TOKEN`](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
 | `push`                        | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
 | `schedule`                    | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
 | `trigger`                     | For pipelines created by using a [trigger token](../triggers/index.md#configure-cicd-jobs-to-run-in-triggered-pipelines).                                                                                                                                           |
diff --git a/doc/ci/pipelines/downstream_pipelines.md b/doc/ci/pipelines/downstream_pipelines.md
index d92a632fce3..4fc7adfaae3 100644
--- a/doc/ci/pipelines/downstream_pipelines.md
+++ b/doc/ci/pipelines/downstream_pipelines.md
@@ -11,7 +11,7 @@ A downstream pipeline can be either:
 
 - A [parent-child pipeline](parent_child_pipelines.md), which is a downstream pipeline triggered
   in the same project as the first pipeline.
-- A [multi-project pipeline](multi_project_pipelines.md), which is a downstream pipeline triggered
+- A [multi-project pipeline](#multi-project-pipelines), which is a downstream pipeline triggered
   in a different project than the first pipeline.
 
 Parent-child pipelines and multi-project pipelines can sometimes be used for similar purposes,
@@ -46,6 +46,132 @@ Multi-project pipelines:
   that happened to be triggered by an external project. They are all visible on the pipeline index page.
 - Are independent, so there are no nesting limits.
 
+## Multi-project pipelines
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+You can set up [GitLab CI/CD](../index.md) across multiple projects, so that a pipeline
+in one project can trigger a downstream pipeline in another project. You can visualize the entire pipeline
+in one place, including all cross-project interdependencies.
+
+For example, you might deploy your web application from three different projects in GitLab.
+Each project has its own build, test, and deploy process. With multi-project pipelines you can
+visualize the entire pipeline, including all build and test stages for all three projects.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
+
+Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
+with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
+Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
+at GitLab@learn, in the Continuous Integration section.
+
+If you trigger a pipeline in a downstream private project, on the upstream project's pipelines page,
+you can view:
+
+- The name of the project.
+- The status of the pipeline.
+
+If you have a public project that can trigger downstream pipelines in a private project,
+make sure there are no confidentiality problems.
+
+### Trigger a multi-project pipeline from a job in your `.gitlab-ci.yml` file
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
+
+When you use the [`trigger`](../yaml/index.md#trigger) keyword to create a multi-project
+pipeline in your `.gitlab-ci.yml` file, you create what is called a *trigger job*. For example:
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  variables:
+    ENVIRONMENT: staging
+  stage: deploy
+  trigger: my/deployment
+```
+
+In this example, after the `rspec` job succeeds in the `test` stage,
+the `staging` trigger job starts. The initial status of this
+job is `pending`.
+
+GitLab then creates a downstream pipeline in the
+`my/deployment` project and, as soon as the pipeline is created, the
+`staging` job succeeds. The full path to the project is `my/deployment`.
+
+You can view the status for the pipeline, or you can display
+[the downstream pipeline's status instead](#mirror-the-status-of-a-downstream-pipeline-in-the-trigger-job).
+
+The user that creates the upstream pipeline must be able to create pipelines in the
+downstream project (`my/deployment`) too. If the downstream project is not found,
+or the user does not have [permission](../../user/permissions.md) to create a pipeline there,
+the `staging` job is marked as _failed_.
+
+#### Specify a downstream pipeline branch
+
+You can specify a branch name for the downstream pipeline to use.
+GitLab uses the commit on the head of the branch to
+create the downstream pipeline.
+
+```yaml
+rspec:
+  stage: test
+  script: bundle exec rspec
+
+staging:
+  stage: deploy
+  trigger:
+    project: my/deployment
+    branch: stable-11-2
+```
+
+Use:
+
+- The `project` keyword to specify the full path to a downstream project.
+  In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/367660), variable expansion is
+  supported.
+- The `branch` keyword to specify the name of a branch in the project specified by `project`.
+  In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is
+  supported.
+
+Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
+of the user that ran the trigger job in the upstream project. If the user does not
+have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
+[pipeline security for protected branches](index.md#pipeline-security-on-protected-branches).
+
+#### Use `rules` or `only`/`except` with multi-project pipelines
+
+You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
+[control job behavior](../jobs/job_control.md) for multi-project pipelines. When a
+downstream pipeline is triggered with the [`trigger`](../yaml/index.md#trigger) keyword,
+the value of the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md)
+is `pipeline` for all its jobs.
+
+If you use [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
+[`pipelines`](../yaml/index.md#onlyrefs--exceptrefs) keyword.
+
+### Trigger a multi-project pipeline by using the API
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
+
+When you use the [`CI_JOB_TOKEN` to trigger pipelines](../jobs/ci_job_token.md),
+GitLab recognizes the source of the job token. The pipelines become related,
+so you can visualize their relationships on pipeline graphs.
+
+These relationships are displayed in the pipeline graph by showing inbound and
+outbound connections for upstream and downstream pipeline dependencies.
+
+When using:
+
+- CI/CD variables or [`rules`](../yaml/index.md#rulesif) to control job behavior, the value of
+  the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md) is
+  `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
+- [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
+  `pipelines` keyword.
+
 ## View a downstream pipeline
 
 In the [pipeline graph view](index.md#view-full-pipeline-graph), downstream pipelines display
@@ -86,6 +212,108 @@ trigger_job:
     strategy: depend
 ```
 
+### View multi-project pipelines in pipeline graphs **(PREMIUM)**
+
+When you trigger a multi-project pipeline, the downstream pipeline displays
+to the right of the [pipeline graph](index.md#visualize-pipelines).
+
+![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
+
+In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
+displays to the right of the mini graph.
+
+![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
+
+## Pass artifacts to a downstream pipeline
+
+You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
+
+1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
+1. Trigger the downstream pipeline with a trigger job:
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   deploy:
+     stage: deploy
+     trigger: my/downstream_project
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set `job` to the job in the upstream pipeline to fetch artifacts from,
+   `ref` to the branch, and `artifacts: true`.
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: main
+         artifacts: true
+   ```
+
+### Pass artifacts from a Merge Request pipeline
+
+When you use `needs:project` to [pass artifacts to a downstream pipeline](#pass-artifacts-to-a-downstream-pipeline),
+the `ref` value is usually a branch name, like `main` or `development`.
+
+For merge request pipelines, the `ref` value is in the form of `refs/merge-requests/<id>/head`,
+where `id` is the merge request ID. You can retrieve this ref with the [`CI_MERGE_REQUEST_REF_PATH`](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
+CI/CD variable. Do not use a branch name as the `ref` with merge request pipelines,
+because the downstream pipeline attempts to fetch artifacts from the latest branch pipeline.
+
+To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
+pass this variable to the downstream pipeline using variable inheritance:
+
+1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
+1. In the job that triggers the downstream pipeline, pass the `$CI_MERGE_REQUEST_REF_PATH` variable by using
+   [variable inheritance](#pass-yaml-defined-cicd-variables):
+
+   ```yaml
+   build_artifacts:
+     stage: build
+     script:
+       - echo "This is a test artifact!" >> artifact.txt
+     artifacts:
+       paths:
+         - artifact.txt
+
+   upstream_job:
+     variables:
+       UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
+     trigger:
+       project: my/downstream_project
+       branch: my-branch
+   ```
+
+1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
+   by using `needs:project`. Set the `ref` to the `UPSTREAM_REF` variable, and `job`
+   to the job in the upstream pipeline to fetch artifacts from:
+
+   ```yaml
+   test:
+     stage: test
+     script:
+       - cat artifact.txt
+     needs:
+       - project: my/upstream_project
+         job: build_artifacts
+         ref: UPSTREAM_REF
+         artifacts: true
+   ```
+
+This method works for fetching artifacts from a regular merge request parent pipeline,
+but fetching artifacts from [merge results](merged_results_pipelines.md) pipelines is not supported.
+
 ## Pass CI/CD variables to a downstream pipeline
 
 You can pass CI/CD variables to a downstream pipeline with a few different methods,
@@ -96,7 +324,7 @@ based on where the variable is created or defined.
 You can use the `variables` keyword to pass CI/CD variables to a downstream pipeline,
 just like you would for any other job.
 
-For example, in a [multi-project pipeline](multi_project_pipelines.md):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 rspec:
@@ -130,7 +358,7 @@ trigger-downstream:
 ### Prevent global variables from being passed
 
 You can stop global variables from reaching the downstream pipeline by using the [`inherit:variables` keyword](../yaml/index.md#inheritvariables).
-For example, in a [multi-project pipeline](multi_project_pipelines.md):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 variables:
@@ -150,7 +378,7 @@ In this example, the `MY_GLOBAL_VAR` variable is not available in the triggered
 
 You might want to pass some information about the upstream pipeline using predefined variables.
 To do that, you can use interpolation to pass any variable. For example,
-in a [multi-project pipeline](multi_project_pipelines.md):
+in a [multi-project pipeline](#multi-project-pipelines):
 
 ```yaml
 downstream-job:
@@ -175,7 +403,7 @@ the ones defined in the upstream project take precedence.
 You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job)
 and [`needs:project`](../yaml/index.md#needsproject).
 
-For example, in a [multi-project pipeline](multi_project_pipelines.md):
+For example, in a [multi-project pipeline](#multi-project-pipelines):
 
 1. Save the variables in a `.env` file.
 1. Save the `.env` file as a `dotenv` report.
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 0b43eff3d2c..59ad47765b1 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -60,7 +60,7 @@ Pipelines can be configured in many different ways:
 - [Parent-child pipelines](parent_child_pipelines.md) break down complex pipelines
   into one parent pipeline that can trigger multiple child sub-pipelines, which all
   run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos.
-- [Multi-project pipelines](multi_project_pipelines.md) combine pipelines for different projects together.
+- [Multi-project pipelines](downstream_pipelines.md#multi-project-pipelines) combine pipelines for different projects together.
 
 ## Configure a pipeline
 
@@ -382,8 +382,8 @@ You can group the jobs by:
 - [Job dependencies](#view-job-dependencies-in-the-pipeline-graph), which arranges
   jobs based on their [`needs`](../yaml/index.md#needs) dependencies.
 
-[Multi-project pipeline graphs](multi_project_pipelines.md#multi-project-pipeline-visualization) help
-you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
+[Multi-project pipeline graphs](downstream_pipelines.md#view-multi-project-pipelines-in-pipeline-graphs) help
+you visualize the entire pipeline, including all cross-project inter-dependencies.
 
 If a stage contains more than 100 jobs, only the first 100 jobs are listed in the
 pipeline graph. The remaining jobs still run as normal. To see the jobs:
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index 6ca42479e8e..00c898a7e0e 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -460,3 +460,54 @@ setting is enabled.
 
 When this setting is enabled, job artifacts from the latest successful pipeline
 of each ref do not expire and are not deleted.
+
+### Error message `This job could not start because it could not retrieve the needed artifacts.`
+
+A job configured with [`needs:artifacts`](../yaml/index.md#needsartifacts) keyword
+fails to start and returns this error message if:
+
+- The job's dependencies cannot be found.
+- The job cannot access the relevant resources due to insufficient permissions.
+
+The troubleshooting steps to follow are determined by the syntax used in the job configuration.
+
+#### Job configured with `needs:project`
+
+The `could not retrieve the needed artifacts.` error can happen for a job using
+[`needs:project`](../yaml/index.md#needsproject), with a configuration similar to:
+
+```yaml
+rspec:
+  needs:
+    - project: org/another-project
+      job: dependency-job
+      ref: master
+      artifacts: true
+```
+
+To troubleshoot this job, verify that:
+
+- Project `org/another-project` is in a group with a Premium subscription plan.
+- The user running the job has permissions to access resources in `org/another-project`.
+- The `project`, `job`, and `ref` combination exists and results in the desired dependency.
+- Any variables in use evaluate to the correct values.
+
+#### Job configured with `needs:pipeline:job`
+
+The `could not retrieve the needed artifacts.` error can happen for a job using
+[`needs:pipeline:job`](../yaml/index.md#needspipelinejob), with a configuration similar to:
+
+```yaml
+rspec:
+  needs:
+    - pipeline: $UPSTREAM_PIPELINE_ID
+      job: dependency-job
+      artifacts: true
+```
+
+To troubleshoot this job, verify that:
+
+- The `$UPSTREAM_PIPELINE_ID` CI/CD variable is available in the current pipeline's
+   parent-child pipeline hierarchy.
+- The `pipeline` and `job` combination exists and resolves to an existing pipeline.
+- `dependency-job` has run and finished successfully.
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index 1664c62f98f..824f1445818 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -1,257 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Authoring
-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
-type: reference
+redirect_to: 'downstream_pipelines.md'
+remove_date: '2022-11-31'
 ---
 
-# Multi-project pipelines **(FREE)**
+This document was moved to [another location](downstream_pipelines.md).
 
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
-
-You can set up [GitLab CI/CD](../index.md) across multiple projects, so that a pipeline
-in one project can trigger a [downstream](downstream_pipelines.md) pipeline in another project. You can visualize the entire pipeline
-in one place, including all cross-project interdependencies.
-
-For example, you might deploy your web application from three different projects in GitLab.
-Each project has its own build, test, and deploy process. With multi-project pipelines you can
-visualize the entire pipeline, including all build and test stages for all three projects.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, see the [Multi-project pipelines demo](https://www.youtube.com/watch?v=g_PIwBM1J84).
-
-Multi-project pipelines are also useful for larger products that require cross-project interdependencies, like those
-with a [microservices architecture](https://about.gitlab.com/blog/2016/08/16/trends-in-version-control-land-microservices/).
-Learn more in the [Cross-project Pipeline Triggering and Visualization demo](https://about.gitlab.com/learn/)
-at GitLab@learn, in the Continuous Integration section.
-
-If you trigger a pipeline in a downstream private project, on the upstream project's pipelines page,
-you can view:
-
-- The name of the project.
-- The status of the pipeline.
-
-If you have a public project that can trigger downstream pipelines in a private project,
-make sure there are no confidentiality problems.
-
-## Create multi-project pipelines
-
-To create multi-project pipelines, you can:
-
-- [Define them in your `.gitlab-ci.yml` file](#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
-- [Use the API](#create-multi-project-pipelines-by-using-the-api).
-
-### Define multi-project pipelines in your `.gitlab-ci.yml` file
-
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
-
-When you use the [`trigger`](../yaml/index.md#trigger) keyword to create a multi-project
-pipeline in your `.gitlab-ci.yml` file, you create what is called a *trigger job*. For example:
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  variables:
-    ENVIRONMENT: staging
-  stage: deploy
-  trigger: my/deployment
-```
-
-In this example, after the `rspec` job succeeds in the `test` stage,
-the `staging` trigger job starts. The initial status of this
-job is `pending`.
-
-GitLab then creates a downstream pipeline in the
-`my/deployment` project and, as soon as the pipeline is created, the
-`staging` job succeeds. The full path to the project is `my/deployment`.
-
-You can view the status for the pipeline, or you can display
-[the downstream pipeline's status instead](downstream_pipelines.md#mirror-the-status-of-a-downstream-pipeline-in-the-trigger-job).
-
-The user that creates the upstream pipeline must be able to create pipelines in the
-downstream project (`my/deployment`) too. If the downstream project is not found,
-or the user does not have [permission](../../user/permissions.md) to create a pipeline there,
-the `staging` job is marked as _failed_.
-
-#### Trigger job configuration limitations
-
-Trigger jobs can use only a limited set of the GitLab CI/CD [configuration keywords](../yaml/index.md).
-The keywords available for use in trigger jobs are:
-
-- [`trigger`](../yaml/index.md#trigger)
-- [`stage`](../yaml/index.md#stage)
-- [`allow_failure`](../yaml/index.md#allow_failure)
-- [`rules`](../yaml/index.md#rules)
-- [`only` and `except`](../yaml/index.md#only--except)
-- [`when`](../yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
-- [`extends`](../yaml/index.md#extends)
-- [`needs`](../yaml/index.md#needs), but not [`needs:project`](../yaml/index.md#needsproject)
-
-Trigger jobs cannot use [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
-
-#### Specify a downstream pipeline branch
-
-You can specify a branch name for the downstream pipeline to use.
-GitLab uses the commit on the head of the branch to
-create the downstream pipeline.
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
-
-staging:
-  stage: deploy
-  trigger:
-    project: my/deployment
-    branch: stable-11-2
-```
-
-Use:
-
-- The `project` keyword to specify the full path to a downstream project.
-  In [GitLab 15.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/367660), variable expansion is
-  supported.
-- The `branch` keyword to specify the name of a branch in the project specified by `project`.
-  In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is
-  supported.
-
-Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
-of the user that ran the trigger job in the upstream project. If the user does not
-have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
-[pipeline security for protected branches](index.md#pipeline-security-on-protected-branches).
-
-#### Pass artifacts to a downstream pipeline
-
-You can pass artifacts to a downstream pipeline by using [`needs:project`](../yaml/index.md#needsproject).
-
-1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
-1. Trigger the downstream pipeline with a trigger job:
-
-   ```yaml
-   build_artifacts:
-     stage: build
-     script:
-       - echo "This is a test artifact!" >> artifact.txt
-     artifacts:
-       paths:
-         - artifact.txt
-
-   deploy:
-     stage: deploy
-     trigger: my/downstream_project
-   ```
-
-1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
-   by using `needs:project`. Set `job` to the job in the upstream pipeline to fetch artifacts from,
-   `ref` to the branch, and `artifacts: true`.
-
-   ```yaml
-   test:
-     stage: test
-     script:
-       - cat artifact.txt
-     needs:
-       - project: my/upstream_project
-         job: build_artifacts
-         ref: main
-         artifacts: true
-   ```
-
-#### Pass artifacts to a downstream pipeline from a Merge Request pipeline
-
-When you use `needs:project` to [pass artifacts to a downstream pipeline](#pass-artifacts-to-a-downstream-pipeline),
-the `ref` value is usually a branch name, like `main` or `development`.
-
-For merge request pipelines, the `ref` value is in the form of `refs/merge-requests/<id>/head`,
-where `id` is the merge request ID. You can retrieve this ref with the [`CI_MERGE_REQUEST_REF_PATH`](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines)
-CI/CD variable. Do not use a branch name as the `ref` with merge request pipelines,
-because the downstream pipeline attempts to fetch artifacts from the latest branch pipeline.
-
-To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
-pass this variable to the downstream pipeline using variable inheritance:
-
-1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
-1. In the job that triggers the downstream pipeline, pass the `$CI_MERGE_REQUEST_REF_PATH` variable by using
-   [variable inheritance](downstream_pipelines.md#pass-yaml-defined-cicd-variables):
-
-   ```yaml
-   build_artifacts:
-     stage: build
-     script:
-       - echo "This is a test artifact!" >> artifact.txt
-     artifacts:
-       paths:
-         - artifact.txt
-
-   upstream_job:
-     variables:
-       UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
-     trigger:
-       project: my/downstream_project
-       branch: my-branch
-   ```
-
-1. In a job in the downstream pipeline, fetch the artifacts from the upstream pipeline
-   by using `needs:project`. Set the `ref` to the `UPSTREAM_REF` variable, and `job`
-   to the job in the upstream pipeline to fetch artifacts from:
-
-   ```yaml
-   test:
-     stage: test
-     script:
-       - cat artifact.txt
-     needs:
-       - project: my/upstream_project
-         job: build_artifacts
-         ref: UPSTREAM_REF
-         artifacts: true
-   ```
-
-This method works for fetching artifacts from a regular merge request parent pipeline,
-but fetching artifacts from [merge results](merged_results_pipelines.md) pipelines is not supported.
-
-#### Use `rules` or `only`/`except` with multi-project pipelines
-
-You can use CI/CD variables or the [`rules`](../yaml/index.md#rulesif) keyword to
-[control job behavior](../jobs/job_control.md) for multi-project pipelines. When a
-downstream pipeline is triggered with the [`trigger`](../yaml/index.md#trigger) keyword,
-the value of the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md)
-is `pipeline` for all its jobs.
-
-If you use [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
-[`pipelines`](../yaml/index.md#onlyrefs--exceptrefs) keyword.
-
-### Create multi-project pipelines by using the API
-
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
-
-When you use the [`CI_JOB_TOKEN` to trigger pipelines](../jobs/ci_job_token.md),
-GitLab recognizes the source of the job token. The pipelines become related,
-so you can visualize their relationships on pipeline graphs.
-
-These relationships are displayed in the pipeline graph by showing inbound and
-outbound connections for upstream and downstream pipeline dependencies.
-
-When using:
-
-- CI/CD variables or [`rules`](../yaml/index.md#rulesif) to control job behavior, the value of
-  the [`$CI_PIPELINE_SOURCE` predefined variable](../variables/predefined_variables.md) is
-  `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
-- [`only/except`](../yaml/index.md#only--except) to control job behavior, use the
-  `pipelines` keyword.
-
-## Multi-project pipeline visualization **(PREMIUM)**
-
-When your pipeline triggers a downstream pipeline, the downstream pipeline displays
-to the right of the [pipeline graph](index.md#visualize-pipelines).
-
-![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
-
-In [pipeline mini graphs](index.md#pipeline-mini-graphs), the downstream pipeline
-displays to the right of the mini graph.
-
-![Multi-project pipeline mini graph](img/pipeline_mini_graph_v15_0.png)
+<!-- This redirect file can be deleted after <2022-11-31>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md
index ede90178a35..56c51d7b119 100644
--- a/doc/ci/pipelines/parent_child_pipelines.md
+++ b/doc/ci/pipelines/parent_child_pipelines.md
@@ -25,7 +25,7 @@ YAML is dynamically generated.
 
 ![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v14_3.png)
 
-Similarly to [multi-project pipelines](multi_project_pipelines.md), a pipeline can trigger a
+Similarly to [multi-project pipelines](downstream_pipelines.md#multi-project-pipelines), a pipeline can trigger a
 set of concurrently running [downstream](downstream_pipelines.md) child pipelines, but in the same project:
 
 - Child pipelines still execute each of their jobs according to a stage sequence, but
@@ -89,7 +89,7 @@ microservice_a:
 
 The maximum number of entries that are accepted for `trigger:include` is three.
 
-Similar to [multi-project pipelines](multi_project_pipelines.md), we can set the
+Similar to [multi-project pipelines](downstream_pipelines.md#multi-project-pipelines), we can set the
 parent pipeline to [depend on the status](downstream_pipelines.md#mirror-the-status-of-a-downstream-pipeline-in-the-trigger-job)
 of the child pipeline upon completion:
 
diff --git a/doc/ci/triggers/index.md b/doc/ci/triggers/index.md
index 2c916ba092c..7df5c91ce38 100644
--- a/doc/ci/triggers/index.md
+++ b/doc/ci/triggers/index.md
@@ -13,7 +13,7 @@ to the [pipeline triggers API endpoint](../../api/pipeline_triggers.md).
 When authenticating with the API, you can use:
 
 - A [trigger token](#create-a-trigger-token) to trigger a branch or tag pipeline.
-- A [CI/CD job token](../jobs/ci_job_token.md) to trigger a [multi-project pipeline](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api).
+- A [CI/CD job token](../jobs/ci_job_token.md) to [trigger a multi-project pipeline](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api).
 
 ## Create a trigger token
 
@@ -169,7 +169,7 @@ To [configure when to run jobs](../jobs/job_control.md) in triggered pipelines:
 | `$CI_PIPELINE_SOURCE` value | `only`/`except` keywords | Trigger method      |
 |-----------------------------|--------------------------|---------------------|
 | `trigger`                   | `triggers`               | In pipelines triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using a [trigger token](#create-a-trigger-token). |
-| `pipeline`                  | `pipelines`              | In [multi-project pipelines](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api) triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using the [`$CI_JOB_TOKEN`](../jobs/ci_job_token.md), or by using the [`trigger`](../yaml/index.md#trigger) keyword in the CI/CD configuration file. |
+| `pipeline`                  | `pipelines`              | In [multi-project pipelines](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api) triggered with the [pipeline triggers API](../../api/pipeline_triggers.md) by using the [`$CI_JOB_TOKEN`](../jobs/ci_job_token.md), or by using the [`trigger`](../yaml/index.md#trigger) keyword in the CI/CD configuration file. |
 
 Additionally, the `$CI_PIPELINE_TRIGGERED` predefined CI/CD variable is set to `true`
 in pipelines triggered with a trigger token.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 287594902b2..34bd0602ca5 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -87,7 +87,7 @@ and [templates](examples/index.md#cicd-templates).
 Some pipeline types have their own detailed usage guides that you should read
 if you are using that type:
 
-- [Multi-project pipelines](pipelines/multi_project_pipelines.md): Have your pipeline trigger
+- [Multi-project pipelines](pipelines/downstream_pipelines.md#multi-project-pipelines): Have your pipeline trigger
   a pipeline in a different project.
 - [Parent/child pipelines](pipelines/parent_child_pipelines.md): Have your main pipeline trigger
   and run separate pipelines in the same project. You can also
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 6f6ac2421ec..a5d881b6864 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -2469,7 +2469,7 @@ when to add jobs to pipelines.
   | `external`               | When you use CI services other than GitLab. |
   | `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)). |
   | `merge_requests`         | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
-  | `pipelines`              | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](#trigger) keyword. |
+  | `pipelines`              | For [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines) created by [using the API with `CI_JOB_TOKEN`](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api), or the [`trigger`](#trigger) keyword. |
   | `pushes`                 | For pipelines triggered by a `git push` event, including for branches and tags. |
   | `schedules`              | For [scheduled pipelines](../pipelines/schedules.md). |
   | `tags`                   | When the Git reference for a pipeline is a tag. |
@@ -3877,18 +3877,31 @@ test:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) in GitLab Premium 11.8.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
 
-Use `trigger` to start a [downstream pipeline](../pipelines/downstream_pipelines.md) that is either:
+Use `trigger` to declare that a job is a "trigger job" which starts a
+[downstream pipeline](../pipelines/downstream_pipelines.md) that is either:
 
-- [A multi-project pipeline](../pipelines/multi_project_pipelines.md).
+- [A multi-project pipeline](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 - [A child pipeline](../pipelines/parent_child_pipelines.md).
 
+Trigger jobs can use only a limited set of the GitLab CI/CD configuration keywords.
+The keywords available for use in trigger jobs are:
+
+- [`trigger`](#trigger).
+- [`stage`](#stage).
+- [`allow_failure`](#allow_failure).
+- [`rules`](#rules).
+- [`only` and `except`](#only--except).
+- [`when`](#when) (only with a value of `on_success`, `on_failure`, or `always`).
+- [`extends`](#extends).
+- [`needs`](#needs), but not [`needs:project`](#needsproject).
+
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
 **Possible inputs**:
 
 - For multi-project pipelines, path to the downstream project. CI/CD variables
   [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
-  in GitLab 15.3 and later.
+  in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
 - For child pipelines, path to the child pipeline CI/CD configuration file.
 
 **Example of `trigger` for multi-project pipeline**:
@@ -3913,9 +3926,6 @@ trigger_job:
 
 **Additional details**:
 
-- Jobs with `trigger` can only use a [limited set of keywords](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
-  For example, you can't run commands with [`script`](#script), [`before_script`](#before_script),
-  or [`after_script`](#after_script). Also, [`environment`](#environment) is not supported with `trigger`.
 - You [cannot use the API to start `when:manual` trigger jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/284086).
 - In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
   can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
@@ -3931,7 +3941,7 @@ trigger_job:
 
 **Related topics**:
 
-- [Multi-project pipeline configuration examples](../pipelines/multi_project_pipelines.md#define-multi-project-pipelines-in-your-gitlab-ciyml-file).
+- [Multi-project pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-from-a-job-in-your-gitlab-ciyml-file).
 - [Child pipeline configuration examples](../pipelines/parent_child_pipelines.md#examples).
 - To run a pipeline for a specific branch, tag, or commit, you can use a [trigger token](../triggers/index.md)
   to authenticate with the [pipeline triggers API](../../api/pipeline_triggers.md).
@@ -3978,7 +3988,7 @@ successfully complete before starting.
 
 Use `trigger:forward` to specify what to forward to the downstream pipeline. You can control
 what is forwarded to both [parent-child pipelines](../pipelines/parent_child_pipelines.md)
-and [multi-project pipelines](../pipelines/multi_project_pipelines.md).
+and [multi-project pipelines](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 
 **Possible inputs**:
 
diff --git a/doc/development/documentation/review_apps.md b/doc/development/documentation/review_apps.md
index 8cb9e6437b8..a50efceb307 100644
--- a/doc/development/documentation/review_apps.md
+++ b/doc/development/documentation/review_apps.md
@@ -57,7 +57,7 @@ If you want to know the in-depth details, here's what's really happening:
 The following GitLab features are used among others:
 
 - [Manual jobs](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually)
-- [Multi project pipelines](../../ci/pipelines/multi_project_pipelines.md)
+- [Multi project pipelines](../../ci/pipelines/downstream_pipelines.md#multi-project-pipelines)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/index.md#artifacts)
 - [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index b8558fcedf2..760ddb96430 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -1157,13 +1157,16 @@ A site profile contains:
 - **Target URL**: The URL that DAST runs against.
 - **Excluded URLs**: A comma-separated list of URLs to exclude from the scan.
 - **Request headers**: A comma-separated list of HTTP request headers, including names and values. These headers are added to every request made by DAST.
-- **Authentication**:
+- **Authentication (for website)**:
   - **Authenticated URL**: The URL of the page containing the sign-in HTML form on the target website. The username and password are submitted with the login form to create an authenticated scan.
   - **Username**: The username used to authenticate to the website.
   - **Password**: The password used to authenticate to the website.
   - **Username form field**: The name of username field at the sign-in HTML form.
   - **Password form field**: The name of password field at the sign-in HTML form.
   - **Submit form field**: The `id` or `name` of the element that when clicked submits the sign-in HTML form.
+- **Authentication (for API scan)**:
+  - **Username**: The username used to authenticate to the API.
+  - **Password**: The password used to authenticate to the API.
 
 When an API site type is selected, a [host override](#host-override) is used to ensure the API being scanned is on the same host as the target. This is done to reduce the risk of running an active scan against the wrong API.
 
diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md
index 4673b9c0ed3..d6bcb0a2018 100644
--- a/doc/user/project/import/svn.md
+++ b/doc/user/project/import/svn.md
@@ -10,76 +10,82 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 GitLab uses Git as its version control system. If you're using Subversion (SVN) as your version control system,
 you can migrate to using a Git repository in GitLab using `svn2git`.
 
-## Migrate using `svn2git`
-
-NOTE:
-Any issues with svn2git should be directed to the [relevant project and maintainer](https://github.com/nirvdrum/svn2git).
-Check for existing issues and history for update frequency.
-
-If you are currently using an SVN repository, you can migrate the repository
-to Git and GitLab. We recommend a hard cut over - run the migration command once
-and then have all developers start using the new GitLab repository immediately.
-Otherwise, it's hard to keep changing in sync in both directions. The conversion
-process should be run on a local workstation.
-
-Install `svn2git`. On all systems you can install as a Ruby gem if you already
-have Ruby and Git installed.
-
-```shell
-sudo gem install svn2git
-```
-
-On Debian-based Linux distributions you can install the native packages:
-
-```shell
-sudo apt-get install git-core git-svn ruby
-```
-
-Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors.
-If you choose not to create the authors file then commits are not attributed
-to the correct GitLab user. Some users may not consider this a big issue while
-others want to ensure they complete this step. If you choose to map authors,
-you must map every author present on changes in the SVN
-repository. If you don't, the conversion fails and you have to update
-the author file accordingly. The following command searches through the
-repository and output a list of authors.
-
-```shell
-svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
-```
-
-Use the output from the last command to construct the authors file.
-Create a file called `authors.txt` and add one mapping per line.
-
-```plaintext
-janedoe = Jane Doe <janedoe@example.com>
-johndoe = John Doe <johndoe@example.com>
-```
-
-If your SVN repository is in the standard format (trunk, branches, tags,
-not nested) the conversion is simple. For a non-standard repository see
-[svn2git documentation](https://github.com/nirvdrum/svn2git). The following
-command will checkout the repository and do the conversion in the current
-working directory. Be sure to create a new directory for each repository before
-running the `svn2git` command. The conversion process takes some time.
-
-```shell
-svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
-```
-
-If your SVN repository requires a username and password add the
-`--username <username>` and `--password <password>` flags to the above command.
-`svn2git` also supports excluding certain file paths, branches, tags, and so on. See
-[svn2git documentation](https://github.com/nirvdrum/svn2git) or run
-`svn2git --help` for full documentation on all of the available options.
-
-Create a new GitLab project, into which you push your converted code.
-Copy the SSH or HTTP(S) repository URL from the project page. Add the GitLab
-repository as a Git remote and push all the changes. This pushes all commits,
-branches and tags.
-
-```shell
-git remote add origin git@gitlab.com:<group>/<project>.git
-git push --all origin
-git push --tags origin
-```
+You can follow the steps on this page to migrate to Git if your SVN repository:
+
+- Has a standard format (trunk, branches, and tags).
+- Is not nested.
+
+For a non-standard repository see the [`svn2git` documentation](https://github.com/nirvdrum/svn2git).
+
+We recommend a hard cut over from SVN to Git and GitLab. Run the migration command once and then have all users use the
+new GitLab repository immediately.
+
+## Install `svn2git`
+
+Install `svn2git` on a local workstation rather than the GitLab server:
+
+- On all systems you can install as a Ruby gem if you already have Ruby and Git installed:
+
+  ```shell
+  sudo gem install svn2git
+  ```
+
+- On Debian-based Linux distributions you can install the native packages:
+
+  ```shell
+  sudo apt-get install git-core git-svn ruby
+  ```
+
+## Prepare an authors file (recommended)
+
+Prepare an authors file so `svn2git` can map SVN authors to Git authors. If you choose not to create the authors file,
+commits are not attributed to the correct GitLab user.
+
+To map authors, you must map every author present on changes in the SVN repository. If you don't, the
+migration fails and you have to update the author file accordingly.
+
+1. Search through the SVN repository and output a list of authors:
+
+   ```shell
+   svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
+   ```
+
+1. Use the output from the last command to construct the authors file. Create a file called `authors.txt` and add one
+   mapping per line. For example:
+
+   ```plaintext
+   sidneyjones = Sidney Jones <sidneyjones@example.com>
+   ```
+
+## Migrate SVN repository to Git repository
+
+`svn2git` supports excluding certain file paths, branches, tags, and more. See
+the [`svn2git` documentation](https://github.com/nirvdrum/svn2git) or run `svn2git --help` for full documentation on all of
+the available options.
+
+For each repository to migrate:
+
+1. Create a new directory and change into it.
+1. For repositories that:
+
+   - Don't require a username and password, run:
+
+     ```shell
+     svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
+     ```
+
+   - Do require a username and password, run:
+
+     ```shell
+     svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt --username <username> --password <password>
+     ```
+
+1. Create a new GitLab project for your migrated code.
+1. Copy the SSH or HTTP(S) repository URL from the GitLab project page.
+1. Add the GitLab repository as a Git remote and push all the changes. This pushes all commits, branches, and tags.
+
+   ```shell
+   git remote add origin git@gitlab.example.com:<group>/<project>.git
+   git push --all origin
+   git push --tags origin
+   ```
diff --git a/lib/api/ci/jobs.rb b/lib/api/ci/jobs.rb
index cd5f1f77ced..943cd370e44 100644
--- a/lib/api/ci/jobs.rb
+++ b/lib/api/ci/jobs.rb
@@ -209,8 +209,8 @@ module API
             .select { |_role, role_access_level| role_access_level <= user_access_level }
             .map(&:first)
 
-          environment = if environment_slug = current_authenticated_job.persisted_environment&.slug
-                          { slug: environment_slug }
+          environment = if persisted_environment = current_authenticated_job.persisted_environment
+                          { tier: persisted_environment.tier, slug: persisted_environment.slug }
                         end
 
           # See https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/kubernetes_ci_access.md#apiv4joballowed_agents-api
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 1192b788a06..ab1356dd35c 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -11915,6 +11915,9 @@ msgstr ""
 msgid "DastProfiles|Enable Authentication"
 msgstr ""
 
+msgid "DastProfiles|Enable Basic Authentication"
+msgstr ""
+
 msgid "DastProfiles|Enter URLs in a comma-separated list."
 msgstr ""
 
@@ -23286,6 +23289,9 @@ msgstr ""
 msgid "Learn more about groups."
 msgstr ""
 
+msgid "Learn more about issues."
+msgstr ""
+
 msgid "Learn more about max seats used"
 msgstr ""
 
@@ -42531,6 +42537,9 @@ msgstr ""
 msgid "Use issue weight"
 msgstr ""
 
+msgid "Use issues to collaborate on ideas, solve problems, and plan work"
+msgstr ""
+
 msgid "Use one line per URI"
 msgstr ""
 
diff --git a/qa/qa/runtime/fixtures.rb b/qa/qa/runtime/fixtures.rb
index 41d7ce5d178..d56af9b4872 100644
--- a/qa/qa/runtime/fixtures.rb
+++ b/qa/qa/runtime/fixtures.rb
@@ -49,3 +49,5 @@ module QA
     end
   end
 end
+
+QA::Runtime::Fixtures.prepend_mod_with('Runtime::Fixtures', namespace: QA)
diff --git a/spec/features/issues/user_sees_empty_state_spec.rb b/spec/features/issues/user_sees_empty_state_spec.rb
index b43ba01606a..0e2a7cb4358 100644
--- a/spec/features/issues/user_sees_empty_state_spec.rb
+++ b/spec/features/issues/user_sees_empty_state_spec.rb
@@ -40,8 +40,8 @@ RSpec.describe 'Issues > User sees empty state', :js do
       it 'user sees empty state' do
         visit project_issues_path(project)
 
-        expect(page).to have_content('The Issue Tracker is the place to add things that need to be improved or solved in a project')
-        expect(page).to have_content('Issues can be bugs, tasks or ideas to be discussed. Also, issues are searchable and filterable.')
+        expect(page).to have_content('Use issues to collaborate on ideas, solve problems, and plan work')
+        expect(page).to have_content('Learn more about issues.')
         expect(page).to have_content('New issue')
       end
 
diff --git a/spec/frontend/issues/list/components/issues_list_app_spec.js b/spec/frontend/issues/list/components/issues_list_app_spec.js
index a39853fd29c..fb25ab4c28d 100644
--- a/spec/frontend/issues/list/components/issues_list_app_spec.js
+++ b/spec/frontend/issues/list/components/issues_list_app_spec.js
@@ -1,4 +1,4 @@
-import { GlButton, GlEmptyState, GlLink } from '@gitlab/ui';
+import { GlButton, GlEmptyState } from '@gitlab/ui';
 import * as Sentry from '@sentry/browser';
 import { mount, shallowMount } from '@vue/test-utils';
 import AxiosMockAdapter from 'axios-mock-adapter';
@@ -122,7 +122,6 @@ describe('CE IssuesListApp component', () => {
   const findGlButtons = () => wrapper.findAllComponents(GlButton);
   const findGlButtonAt = (index) => findGlButtons().at(index);
   const findGlEmptyState = () => wrapper.findComponent(GlEmptyState);
-  const findGlLink = () => wrapper.findComponent(GlLink);
   const findIssuableList = () => wrapper.findComponent(IssuableList);
   const findNewIssueDropdown = () => wrapper.findComponent(NewIssueDropdown);
 
@@ -562,15 +561,16 @@ describe('CE IssuesListApp component', () => {
 
         it('shows Jira integration information', () => {
           const paragraphs = wrapper.findAll('p');
-          expect(paragraphs.at(2).text()).toContain(IssuesListApp.i18n.jiraIntegrationTitle);
-          expect(paragraphs.at(3).text()).toContain(
+          const links = wrapper.findAll('.gl-link');
+          expect(paragraphs.at(1).text()).toContain(IssuesListApp.i18n.jiraIntegrationTitle);
+          expect(paragraphs.at(2).text()).toContain(
             'Enable the Jira integration to view your Jira issues in GitLab.',
           );
-          expect(paragraphs.at(4).text()).toContain(
+          expect(paragraphs.at(3).text()).toContain(
             IssuesListApp.i18n.jiraIntegrationSecondaryMessage,
           );
-          expect(findGlLink().text()).toBe('Enable the Jira integration');
-          expect(findGlLink().attributes('href')).toBe(defaultProvide.jiraIntegrationPath);
+          expect(links.at(1).text()).toBe('Enable the Jira integration');
+          expect(links.at(1).attributes('href')).toBe(defaultProvide.jiraIntegrationPath);
         });
       });
 
diff --git a/spec/frontend/vue_shared/components/gl_modal_vuex_spec.js b/spec/frontend/vue_shared/components/gl_modal_vuex_spec.js
index 2dcd91f737f..6dc018797a6 100644
--- a/spec/frontend/vue_shared/components/gl_modal_vuex_spec.js
+++ b/spec/frontend/vue_shared/components/gl_modal_vuex_spec.js
@@ -157,13 +157,13 @@ describe('GlModalVuex', () => {
 
       const handler = modalFooterSlotContent.mock.calls[0][0][handlerName];
 
-      expect(wrapper.emitted(handlerName)).toBeFalsy();
+      expect(wrapper.emitted(handlerName)).toBeUndefined();
       expect(actions.hide).not.toHaveBeenCalled();
 
       handler();
 
       expect(actions.hide).toHaveBeenCalledTimes(1);
-      expect(wrapper.emitted(handlerName)).toBeTruthy();
+      expect(wrapper.emitted(handlerName)).toHaveLength(1);
     },
   );
 });
diff --git a/spec/requests/api/ci/jobs_spec.rb b/spec/requests/api/ci/jobs_spec.rb
index d448b2db26a..b8983e9632e 100644
--- a/spec/requests/api/ci/jobs_spec.rb
+++ b/spec/requests/api/ci/jobs_spec.rb
@@ -249,6 +249,10 @@ RSpec.describe API::Ci::Jobs do
         it 'includes environment slug' do
           expect(json_response.dig('environment', 'slug')).to eq('production')
         end
+
+        it 'includes environment tier' do
+          expect(json_response.dig('environment', 'tier')).to eq('production')
+        end
       end
 
       context 'when non-deployment environment action' do
@@ -260,6 +264,10 @@ RSpec.describe API::Ci::Jobs do
         it 'includes environment slug' do
           expect(json_response.dig('environment', 'slug')).to eq('review')
         end
+
+        it 'includes environment tier' do
+          expect(json_response.dig('environment', 'tier')).to eq('development')
+        end
       end
 
       context 'when passing the token as params' do