Add latest changes from gitlab-org/gitlab@master

15 files changed, 26 insertions, 37 deletions

diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md
index 5d621fb7faf..f54cf84af5d 100644
--- a/doc/user/analytics/value_stream_analytics.md
+++ b/doc/user/analytics/value_stream_analytics.md
@@ -72,9 +72,9 @@ Each stage of Value Stream Analytics is further described in the table below.
 | Issue     | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md#creating-a-new-list) created for it. |
 | Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
 | Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
-| Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
+| Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI/CD takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
 | Review    | Measures the median time taken to review the merge request that has a closing issue pattern, between its creation and until it's merged. |
-| Staging   | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
+| Staging   | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI/CD configuration. If there isn't a production environment, this is not tracked. |
 | Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. |
 
 How this works, behind the scenes:
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index ff4ea13c392..dcbaff70633 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -86,7 +86,7 @@ There are two ways to define the URL to be scanned by DAST:
 
 1. Add it in an `environment_url.txt` file at the root of your project.
     This is great for testing in dynamic environments. In order to run DAST against
-    an app that is dynamically created during a GitLab CI pipeline, have the app
+    an app that is dynamically created during a GitLab CI/CD pipeline, have the app
     persist its domain in an `environment_url.txt` file, and DAST will
     automatically parse that file to find its scan target.
     You can see an [example](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)
diff --git a/doc/user/packages/conan_repository/index.md b/doc/user/packages/conan_repository/index.md
index 3b993303391..aa81b3d056e 100644
--- a/doc/user/packages/conan_repository/index.md
+++ b/doc/user/packages/conan_repository/index.md
@@ -268,7 +268,7 @@ The GitLab Conan repository supports the following Conan CLI commands:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/11678) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.7.
 
-To work with Conan commands within [GitLab CI](./../../../ci/README.md), you can use
+To work with Conan commands within [GitLab CI/CD](./../../../ci/README.md), you can use
 `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
 It is easiest to provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index f4e2b71dd3c..58f0f46052d 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -481,7 +481,7 @@ Docker container), and Maven will utilize the configured CI
 ### Useful Maven command line options
 
 There's some [maven command line options](https://maven.apache.org/ref/current/maven-embedder/cli.html)
-which maybe useful when doing tasks with GitLab CI.
+which maybe useful when doing tasks with GitLab CI/CD.
 
 - File transfer progress can make the CI logs hard to read.
   Option `-ntp,--no-transfer-progress` was added in
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index e5cd45ee707..373e399d56f 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -285,7 +285,7 @@ page.
 
 ## Publishing a package with CI/CD
 
-To work with NPM commands within [GitLab CI](./../../../ci/README.md), you can use
+To work with NPM commands within [GitLab CI/CD](./../../../ci/README.md), you can use
 `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
 A simple example `.gitlab-ci.yml` file for publishing NPM packages:
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index cd8f7e049a3..3df57e3a7a5 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -119,7 +119,7 @@ production:
 
 This example code does the following:
 
-1. Uses the `node:latest` image for all GitLab CI builds
+1. Uses the `node:latest` image for all GitLab CI/CD builds
 1. The `deploy` stage:
    - Installs the Serverless Framework.
    - Deploys the serverless function to your AWS account using the AWS credentials
@@ -164,7 +164,7 @@ That should output:
 }
 ```
 
-Hooray! You now have a AWS Lambda function deployed via GitLab CI.
+Hooray! You now have a AWS Lambda function deployed via GitLab CI/CD.
 
 Nice work!
 
@@ -222,7 +222,7 @@ provider:
 ```
 
 From there, you can reference them in your functions as well.
-Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
+Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
 
 NOTE: **Note:**
 Anyone with access to the AWS environment may be able to see the values of those
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index efffdaab8e5..418e16aa0c1 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -14,7 +14,7 @@ GitLab supports several ways deploy Serverless applications in both Kubernetes E
 Currently we support:
 
 - [Knative](#knative): Build Knative applications with Knative and `gitlabktl` on GKE and EKS.
-- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI.
+- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI/CD.
 
 ## Knative
 
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index c2d7fe89833..daeca8aa614 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -140,7 +140,7 @@ version of your application.
 ## Further reading
 
 - [GitLab Autodeploy][autodeploy]
-- [GitLab CI environment variables][variables]
+- [GitLab CI/CD environment variables][variables]
 - [Environments and deployments][environment]
 - [Kubernetes deploy example][kube-deploy]
 
@@ -153,7 +153,7 @@ version of your application.
 [kube-exec]: https://docs.gitlab.com/runner/executors/kubernetes.html "GitLab Runner Kubernetes executor"
 [kube-service]: integrations/kubernetes.md "Kubernetes project service"
 [review apps]: ../../ci/review_apps/index.md "Review Apps documentation"
-[variables]: ../../ci/variables/README.md "GitLab CI variables"
+[variables]: ../../ci/variables/README.md "GitLab CI/CD variables"
 [autodeploy]: ../../topics/autodevops/index.md#auto-deploy "GitLab Autodeploy"
 [kube-image]: https://gitlab.com/gitlab-examples/kubernetes-deploy/container_registry "Kubernetes deploy Container Registry"
 [runners]: ../../ci/runners/README.md
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 3a356ec0418..f5bb2ee78d9 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -65,7 +65,7 @@ When you create a project in GitLab, you'll have access to a large number of
   images out-of-the-box
   - [Auto Deploy](../../topics/autodevops/index.md#auto-deploy): Configure GitLab CI/CD
   to automatically set up your app's deployment
-  - [Enable and disable GitLab CI](../../ci/enable_or_disable_ci.md)
+  - [Enable and disable GitLab CI/CD](../../ci/enable_or_disable_ci.md)
   - [Pipelines](../../ci/pipelines/index.md): Configure and visualize
     your GitLab CI/CD pipelines from the UI
     - [Scheduled Pipelines](../../ci/pipelines/schedules.md): Schedule a pipeline
diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md
index 51ea070f60a..9ecfcd12b80 100644
--- a/doc/user/project/new_ci_build_permissions_model.md
+++ b/doc/user/project/new_ci_build_permissions_model.md
@@ -186,7 +186,7 @@ echo -e "machine gitlab.com\nlogin gitlab-ci-token\npassword ${CI_JOB_TOKEN}" >
 
 ### Git submodules
 
-To properly configure submodules with GitLab CI, read the
+To properly configure submodules with GitLab CI/CD, read the
 [Git submodules documentation][gitsub].
 
 ### Container Registry
diff --git a/doc/user/project/pages/getting_started_part_four.md b/doc/user/project/pages/getting_started_part_four.md
index d6b34f4319e..645cc1c5795 100644
--- a/doc/user/project/pages/getting_started_part_four.md
+++ b/doc/user/project/pages/getting_started_part_four.md
@@ -40,7 +40,7 @@ need to understand just a few things to be able to write our own
 `.gitlab-ci.yml` or tweak an existing one. It's an
 [Yaml](https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html) file,
 with its own syntax. You can always check your CI syntax with
-the [GitLab CI Lint Tool](https://gitlab.com/ci/lint).
+the [GitLab CI/CD Lint Tool](https://gitlab.com/ci/lint).
 
 ## Practical example
 
@@ -48,7 +48,7 @@ Let's consider you have a [Jekyll](https://jekyllrb.com/) site.
 To build it locally, you would open your terminal, and run `jekyll build`.
 Of course, before building it, you had to install Jekyll in your computer.
 For that, you had to open your terminal and run `gem install jekyll`.
-Right? GitLab CI + GitLab Runner do the same thing. But you need to
+Right? GitLab CI/CD + GitLab Runner do the same thing. But you need to
 write in the `.gitlab-ci.yml` the script you want to run so
 GitLab Runner will do it for you. It looks more complicated than it
 is. What you need to tell the Runner:
@@ -144,7 +144,7 @@ pages:
 That's it! A `.gitlab-ci.yml` with the content above would deploy
 your Jekyll 3.4.0 site with GitLab Pages. This is the minimum
 configuration for our example. On the steps below, we'll refine
-the script by adding extra options to our GitLab CI.
+the script by adding extra options to our GitLab CI/CD.
 
 Artifacts will be automatically deleted once GitLab Pages got deployed.
 You can preserve artifacts for limited time by specifying the expiry time.
@@ -216,7 +216,7 @@ pages:
 Another interesting concept to keep in mind are build stages.
 Your web app can pass through a lot of tests and other tasks
 until it's deployed to staging or production environments.
-There are three default stages on GitLab CI: build, test,
+There are three default stages on GitLab CI/CD: build, test,
 and deploy. To specify which stage your _job_ is running,
 simply add another line to your CI:
 
@@ -279,7 +279,7 @@ parallel. So, if your web app needs more than one test
 before being deployed, you can run all your test at the
 same time, it's not necessary to wait one test to finish
 to run the other. Of course, this is just a brief
-introduction of GitLab CI and GitLab Runner, which are
+introduction of GitLab CI/CD and GitLab Runner, which are
 tools much more powerful than that. This is what you
 need to be able to create and tweak your builds for
 your GitLab Pages site.
@@ -369,22 +369,22 @@ exclude:
   - vendor
 ```
 
-There we go! Now our GitLab CI not only builds our website,
+There we go! Now our GitLab CI/CD not only builds our website,
 but also **continuously test** pushes to feature-branches,
 **caches** dependencies installed with Bundler, and
 **continuously deploy** every push to the `master` branch.
 
 ## Advanced GitLab CI for GitLab Pages
 
-What you can do with GitLab CI is pretty much up to your
+What you can do with GitLab CI/CD is pretty much up to your
 creativity. Once you get used to it, you start creating
 awesome scripts that automate most of tasks you'd do
 manually in the past. Read through the
-[documentation of GitLab CI](../../../ci/yaml/README.md)
+[documentation of GitLab CI/CD](../../../ci/yaml/README.md)
 to understand how to go even further on your scripts.
 
 - On this blog post, understand the concept of
-  [using GitLab CI `environments` to deploy your
+  [using GitLab CI/CD `environments` to deploy your
   web app to staging and production](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/).
 - On this post, learn [how to run jobs sequentially,
   in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/)
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index 4ebe37394b4..02bb8e13f4a 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -95,7 +95,7 @@ To learn more about configuration options for GitLab Pages, read the following:
 | --- | --- |
 | [GitLab Pages domain names, URLs, and baseurls](getting_started_part_one.md) | Understand how GitLab Pages default domains work. |
 | [GitLab CI/CD for GitLab Pages](getting_started_part_four.md) | Understand how to create your own `.gitlab-ci.yml` for your site. |
-| [Exploring GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI's configuration options, Access Control, custom 404 pages, limitations, FAQ. |
+| [Exploring GitLab Pages](introduction.md) | Requirements, technical aspects, specific GitLab CI/CD's configuration options, Access Control, custom 404 pages, limitations, FAQ. |
 |---+---|
 | [Custom domains and SSL/TLS Certificates](custom_domains_ssl_tls_certification/index.md) | How to add custom domains and subdomains to your website, configure DNS records and SSL/TLS certificates. |
 | [Let's Encrypt integration](custom_domains_ssl_tls_certification/lets_encrypt_integration.md) | Secure your Pages sites with Let's Encrypt certificates automatically obtained and renewed by GitLab. |
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index f95ee26a226..798efe6fa1d 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -288,17 +288,6 @@ No, you don't. You can create your project first and it will be accessed under
 
 For a list of known issues, visit GitLab's [public issue tracker].
 
-[jekyll]: http://jekyllrb.com/
-[pages-daemon]: https://gitlab.com/gitlab-org/gitlab-pages
-[gitlab ci]: https://about.gitlab.com/gitlab-ci
-[gitlab runner]: https://docs.gitlab.com/runner/
 [pages]: ../../../ci/yaml/README.md#pages
-[yaml]: ../../../ci/yaml/README.md
-[staticgen]: https://www.staticgen.com/
-[pages-jekyll]: https://gitlab.com/pages/jekyll
 [metarefresh]: https://en.wikipedia.org/wiki/Meta_refresh
 [public issue tracker]: https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=Category%3APages
-[quick start guide]: ../../../ci/quick_start/README.md
-[pages-index-guide]: index.md
-[pages-quick]: getting_started_part_one.md
-[video-pages-fork]: https://youtu.be/TWqh9MtT4Bg
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index 6b0c58e60bd..a9647a9ed0f 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -157,7 +157,7 @@ Via command line, you can commit multiple times before pushing.
   - **Skip pipelines:**
   You can add to you commit message the keyword
   [`[ci skip]`](../../../ci/yaml/README.md#skipping-jobs)
-  and GitLab CI will skip that pipeline.
+  and GitLab CI/CD will skip that pipeline.
   - **Cross-link issues and merge requests:**
   [Cross-linking](../issues/crosslinking_issues.md#from-commit-messages)
   is great to keep track of what's is somehow related in your workflow.
diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md
index a0a4a9f55ea..f18a202c63b 100644
--- a/doc/user/project/service_desk.md
+++ b/doc/user/project/service_desk.md
@@ -24,7 +24,7 @@ For an overview, check the video demonstration on [GitLab Service Desk](https://
 
 For instance, let's assume you develop a game for iOS or Android.
 The codebase is hosted in your GitLab instance, built and deployed
-with GitLab CI.
+with GitLab CI/CD.
 
 Here's how Service Desk will work for you: