Merge branch 'docs-vale-update-substitution' into 'master'

Rename GitLab CI to GitLab CI/CD in docs

See merge request gitlab-org/gitlab!27768

doc/administration/high_availability/nfs.md

@@ -224,7 +224,7 @@ following are the 4 locations need to be shared:
 | `/var/opt/gitlab/git-data` | Git repository data. This will account for a large portion of your data | `git_data_dirs({"default" => { "path" => "/var/opt/gitlab/git-data"} })`
 | `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'`
 | `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
-| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`
+| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI/CD build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`
 
 Other GitLab directories should not be shared between nodes. They contain
 node-specific files and GitLab code that does not need to be shared. To ship

doc/api/README.md

@@ -82,7 +82,7 @@ There are four ways to authenticate with the GitLab API:
 1. [OAuth2 tokens](#oauth2-tokens)
 1. [Personal access tokens](#personal-access-tokens)
 1. [Session cookie](#session-cookie)
-1. [GitLab CI job token](#gitlab-ci-job-token) **(Specific endpoints only)**
+1. [GitLab CI/CD job token](#gitlab-ci-job-token) **(Specific endpoints only)**
 
 For admins who want to authenticate with the API as a specific user, or who want to build applications or scripts that do so, two options are available:
 
@@ -154,7 +154,7 @@ for example, without needing to explicitly pass an access token.
 
 ### GitLab CI job token
 
-With a few API endpoints you can use a [GitLab CI job token](../user/project/new_ci_build_permissions_model.md#job-token)
+With a few API endpoints you can use a [GitLab CI/CD job token](../user/project/new_ci_build_permissions_model.md#job-token)
 to authenticate with the API:
 
 - [Get job artifacts](jobs.md#get-job-artifacts)

doc/api/api_resources.md

@@ -150,5 +150,5 @@ Endpoints are available for:
 
 - [Dockerfile templates](templates/dockerfiles.md).
 - [`.gitignore` templates](templates/gitignores.md).
-- [GitLab CI YAML templates](templates/gitlab_ci_ymls.md).
+- [GitLab CI/CD YAML templates](templates/gitlab_ci_ymls.md).
 - [Open source license templates](templates/licenses.md).

doc/api/issues.md

@@ -1190,8 +1190,8 @@ Example response:
   "id": 112,
   "project": {
     "id": 5,
-    "name": "Gitlab Ci",
-    "name_with_namespace": "Gitlab Org / Gitlab Ci",
+    "name": "GitLab CI/CD",
+    "name_with_namespace": "GitLab Org / GitLab CI/CD",
     "path": "gitlab-ci",
     "path_with_namespace": "gitlab-org/gitlab-ci"
   },

doc/api/merge_requests.md

@@ -2088,8 +2088,8 @@ Example response:
   "id": 113,
   "project": {
     "id": 3,
-    "name": "Gitlab Ci",
-    "name_with_namespace": "Gitlab Org / Gitlab Ci",
+    "name": "GitLab CI/CD",
+    "name_with_namespace": "GitLab Org / GitLab CI/CD",
     "path": "gitlab-ci",
     "path_with_namespace": "gitlab-org/gitlab-ci"
   },

doc/api/project_templates.md

@@ -4,7 +4,7 @@ This API is a project-specific version of these endpoints:
 
 - [Dockerfile templates](templates/dockerfiles.md)
 - [Gitignore templates](templates/gitignores.md)
-- [GitLab CI Config templates](templates/gitlab_ci_ymls.md)
+- [GitLab CI/CD Config templates](templates/gitlab_ci_ymls.md)
 - [Open source license templates](templates/licenses.md)
 
 It deprecates these endpoints, which will be removed for API version 5.

doc/api/services.md

@@ -872,7 +872,7 @@ GET /projects/:id/services/packagist
 
 ## Pipeline-Emails
 
-Get emails for GitLab CI pipelines.
+Get emails for GitLab CI/CD pipelines.
 
 ### Create/Edit Pipeline-Emails service
 

doc/api/templates/gitlab_ci_ymls.md

@@ -4,13 +4,13 @@ type: reference
 
 # GitLab CI YMLs API
 
-In GitLab, there is an API endpoint available to work with CI YMLs. For more
+In GitLab, there is an API endpoint available to work with GitLab CI/CD YMLs. For more
 information on CI/CD pipeline configuration in GitLab, see the
 [configuration reference documentation](../../ci/yaml/README.md).
 
 ## List GitLab CI YML templates
 
-Get all GitLab CI YML templates.
+Get all GitLab CI/CD YML templates.
 
 ```plaintext
 GET /templates/gitlab_ci_ymls
@@ -111,7 +111,7 @@ Example response:
 
 ## Single GitLab CI YML template
 
-Get a single GitLab CI YML template.
+Get a single GitLab CI/CD YML template.
 
 ```plaintext
 GET /templates/gitlab_ci_ymls/:key
@@ -119,7 +119,7 @@ GET /templates/gitlab_ci_ymls/:key
 
 | Attribute  | Type   | Required | Description                           |
 | ---------- | ------ | -------- | ------------------------------------- |
-| `key`      | string | yes      | The key of the GitLab CI YML template |
+| `key`      | string | yes      | The key of the GitLab CI/CD YML template |
 
 Example request:
 

doc/ci/README.md

@@ -160,11 +160,10 @@ See also:
 
 ### Why GitLab CI/CD?
 
-The following articles explain reasons to use GitLab CI/CD
-for your CI/CD infrastructure:
+Learn more about:
 
-- [Why we chose GitLab CI for our CI/CD solution](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/)
-- [Building our web-app on GitLab CI](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/)
+- [Why you might chose GitLab CI/CD](https://about.gitlab.com/blog/2016/10/17/gitlab-ci-oohlala/).
+- [Reasons you might migrate from another platform](https://about.gitlab.com/blog/2016/07/22/building-our-web-app-on-gitlab-ci/).
 - [5 Teams that made the switch to GitLab CI/CD](https://about.gitlab.com/blog/2019/04/25/5-teams-that-made-the-switch-to-gitlab-ci-cd/)
 
 See also the [Why CI/CD?](https://docs.google.com/presentation/d/1OGgk2Tcxbpl7DJaIOzCX4Vqg3dlwfELC3u2jEeCBbDk) presentation.

doc/ci/docker/using_docker_images.md

@@ -4,7 +4,7 @@ type: concepts, howto
 
 # Using Docker images
 
-GitLab CI in conjunction with [GitLab Runner](../runners/README.md) can use
+GitLab CI/CD in conjunction with [GitLab Runner](../runners/README.md) can use
 [Docker Engine](https://www.docker.com/) to test and build any application.
 
 Docker is an open-source project that allows you to use predefined images to
@@ -12,7 +12,7 @@ run applications in independent "containers" that are run within a single Linux
 instance. [Docker Hub][hub] has a rich database of pre-built images that can be
 used to test and build your applications.
 
-When used with GitLab CI, Docker runs each job in a separate and isolated
+When used with GitLab CI/CD, Docker runs each job in a separate and isolated
 container using the predefined image that is set up in
 [`.gitlab-ci.yml`](../yaml/README.md).
 

doc/ci/examples/README.md

@@ -37,7 +37,7 @@ The following table lists examples with step-by-step tutorials that are containe
 | Python on Heroku            | [Test and deploy a Python application with GitLab CI/CD](test-and-deploy-python-application-to-heroku.md).                 |
 | Ruby on Heroku              | [Test and deploy a Ruby application with GitLab CI/CD](test-and-deploy-ruby-application-to-heroku.md).                     |
 | Scala on Heroku             | [Test and deploy a Scala application to Heroku](test-scala-application.md).                                                |
-| Parallel testing Ruby & JS  | [GitLab CI parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
+| Parallel testing Ruby & JS  | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
 
 ### Contributing examples
 
@@ -67,7 +67,7 @@ For examples of setting up GitLab CI/CD for cloud-based environments, see:
 
 See also the following video overviews:
 
-- [Containers, Schedulers, and GitLab CI](https://www.youtube.com/watch?v=d-9awBxEbvQ).
+- [Kubernetes, GitLab, and Cloud Native](https://www.youtube.com/watch?v=d-9awBxEbvQ).
 - [Deploying to IBM Cloud with GitLab CI/CD](https://www.youtube.com/watch?v=6ZF4vgKMd-g).
 
 ### Customer stories

doc/ci/examples/deployment/README.md

@@ -6,7 +6,7 @@ type: tutorial
 
 [Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
 continuous deployment that's developed and used by Travis CI, but can also be
-used with GitLab CI.
+used with GitLab CI/CD.
 
 Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
 

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -100,7 +100,7 @@ Here's the breakdown:
 1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
 1. We connect to SSH and remove the `_old` folder
 
-What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
+What's the deal with the artifacts? We just tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed).
 
 ### Why we do it this way
 

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -608,7 +608,7 @@ If the SSH keys have added successfully, we can run Envoy.
 As mentioned before, GitLab supports [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) methods as well.
 The [environment](../../yaml/README.md#environment) keyword tells GitLab that this job deploys to the `production` environment.
 The `url` keyword is used to generate a link to our application on the GitLab Environments page.
-The `only` keyword tells GitLab CI that the job should be executed only when the pipeline is building the `master` branch.
+The `only` keyword tells GitLab CI/CD that the job should be executed only when the pipeline is building the `master` branch.
 Lastly, `when: manual` is used to turn the job from running automatically to a manual action.
 
 ```yaml
@@ -679,6 +679,6 @@ As you see, the `.env` is pointing to the `/var/www/app/.env` file and also `sto
 
 ## Conclusion
 
-We configured GitLab CI to perform automated tests and used the method of [Continuous Delivery](https://continuousdelivery.com/) to deploy to production a Laravel application with Envoy, directly from the codebase.
+We configured GitLab CI/CD to perform automated tests and used the method of [Continuous Delivery](https://continuousdelivery.com/) to deploy to production a Laravel application with Envoy, directly from the codebase.
 
 Envoy also was a great match to help us deploy the application without writing our custom bash script and doing Linux magics.

doc/ci/examples/test-scala-application.md

@@ -4,7 +4,7 @@ type: tutorial
 
 # Test and deploy a Scala application to Heroku
 
-This example demonstrates the integration of GitLab CI with Scala
+This example demonstrates the integration of GitLab CI/CD with Scala
 applications using SBT. You can view or fork the [example project](https://gitlab.com/gitlab-examples/scala-sbt)
 and view the logs of its past [CI jobs](https://gitlab.com/gitlab-examples/scala-sbt/-/jobs?scope=finished).
 

doc/ci/git_submodules.md

@@ -44,7 +44,7 @@ for all your local checkouts. The `.gitmodules` would look like:
 The above configuration will instruct Git to automatically deduce the URL that
 should be used when cloning sources. Whether you use HTTP(S) or SSH, Git will use
 that same channel and it will allow to make all your CI jobs use HTTP(S)
-(because GitLab CI only uses HTTP(S) for cloning your sources), and all your local
+(because GitLab CI/CD only uses HTTP(S) for cloning your sources), and all your local
 clones will continue using SSH.
 
 For all other submodules not located on the same GitLab server, use the full

doc/ci/jenkins/index.md

@@ -243,7 +243,7 @@ default:
 
 #### `stages`
 
-GitLab CI also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages)
+GitLab CI/CD also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages)
 is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
 the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
 [`stage:` keyword](../yaml/README.md#stage).

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -66,7 +66,7 @@ otherwise pipelines for merged results won't run and your merge requests will be
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12996) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
 
-GitLab CI can detect the presence of redundant pipelines,
+GitLab CI/CD can detect the presence of redundant pipelines,
 and will cancel them automatically in order to conserve CI resources.
 
 When a user merges a merge request immediately within an ongoing merge

doc/ci/multi_project_pipelines.md

@@ -39,7 +39,7 @@ With Multi-Project Pipelines you can visualize the entire pipeline, including al
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2121) in [GitLab Premium 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs).
 
-When you configure GitLab CI for your project, you can visualize the stages of your
+When you configure GitLab CI/CD for your project, you can visualize the stages of your
 [jobs](pipelines/index.md#configuring-pipelines) on a [pipeline graph](pipelines/index.md#visualizing-pipelines).
 
 ![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)

doc/ci/parent_child_pipelines.md

@@ -33,7 +33,7 @@ set of concurrently running child pipelines, but within the same project:
 - Imports are done at the child pipeline level, reducing the likelihood of collisions.
 - Each pipeline has only relevant steps, making it easier to understand what's going on.
 
-Child pipelines work well with other GitLab CI features:
+Child pipelines work well with other GitLab CI/CD features:
 
 - Use [`only: changes`](yaml/README.md#onlychangesexceptchanges) to trigger pipelines only when
   certain files change. This is useful for monorepos, for example.

doc/ci/pipelines/schedules.md

@@ -46,7 +46,7 @@ is installed on.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12328) in GitLab 9.4.
 
 You can pass any number of arbitrary variables and they will be available in
-GitLab CI so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).
+GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).
 
 ![Scheduled pipeline variables](img/pipeline_schedule_variables.png)
 

doc/ci/quick_start/README.md

@@ -55,7 +55,7 @@ This guide assumes that you have:
 - A project in GitLab that you would like to use CI for.
 - Maintainer or owner access to the project
 
-Let's break it down to pieces and work on solving the GitLab CI puzzle.
+Let's break it down to pieces and work on solving the GitLab CI/CD puzzle.
 
 ## Creating a `.gitlab-ci.yml` file
 

doc/ci/runners/README.md

@@ -4,12 +4,12 @@ type: reference
 
 # Configuring GitLab Runners
 
-In GitLab CI, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md).
+In GitLab CI/CD, Runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md).
 They are isolated (virtual) machines that pick up jobs through the coordinator
-API of GitLab CI.
+API of GitLab CI/CD.
 
 A Runner can be specific to a certain project or serve any project
-in GitLab CI. A Runner that serves all projects is called a shared Runner.
+in GitLab CI/CD. A Runner that serves all projects is called a shared Runner.
 
 Ideally, the GitLab Runner should not be installed on the same machine as GitLab.
 Read the [requirements documentation](../../install/requirements.md#gitlab-runner)

doc/ci/triggers/README.md

@@ -192,7 +192,7 @@ https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=T
 ## Making use of trigger variables
 
 You can pass any number of arbitrary variables in the trigger API call and they
-will be available in GitLab CI so that they can be used in your `.gitlab-ci.yml`
+will be available in GitLab CI/CD so that they can be used in your `.gitlab-ci.yml`
 file. The parameter is of the form:
 
 ```plaintext

doc/ci/variables/README.md

@@ -317,7 +317,7 @@ export GITLAB_USER_ID="42"
 NOTE: **Note:**
 This feature requires GitLab Runner 0.5.0 or higher and GitLab 7.14 or higher.
 
-GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in the
+GitLab CI/CD allows you to add to `.gitlab-ci.yml` variables that are set in the
 build environment. The variables are hence saved in the repository, and they
 are meant to store non-sensitive project configuration. For example, `RAILS_ENV` or
 `DATABASE_URL`.

doc/ci/variables/predefined_variables.md

@@ -56,7 +56,7 @@ future GitLab releases.**
 | `CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA`  | 12.3   | all    | The HEAD SHA of the source branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open.                                                                               |
 | `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME` | 12.3   | all    | The target branch name of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open.                                                                                          |
 | `CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA`  | 12.3   | all    | The HEAD SHA of the target branch of the pull request if [the pipelines are for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). Available only if `only: [external_pull_requests]` or [`rules`](../yaml/README.md#rules) syntax is used and the pull request is open.                                                                               |
-| `CI_JOB_ID`                                   | 9.0    | all    | The unique id of the current job that GitLab CI uses internally                                                                                                                                                                                                                                                                                            |
+| `CI_JOB_ID`                                   | 9.0    | all    | The unique id of the current job that GitLab CI/CD uses internally                                                                                                                                                                                                                                                                                            |
 | `CI_JOB_IMAGE`                                | 12.9   | 12.9   | The name of the image running the CI job                                                                                                                                                                                                                                                                                                                   |
 | `CI_JOB_MANUAL`                               | 8.12   | all    | The flag to indicate that job was manually started                                                                                                                                                                                                                                                                                                         |
 | `CI_JOB_NAME`                                 | 9.0    | 0.5    | The name of the job as defined in `.gitlab-ci.yml`                                                                                                                                                                                                                                                                                                         |
@@ -87,13 +87,13 @@ future GitLab releases.**
 | `CI_NODE_TOTAL`                               | 11.5   | all    | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`.                                                                                                                                                                                                                                    |
 | `CI_PAGES_DOMAIN`                             | 11.8   | all    | The configured domain that hosts GitLab Pages.                                                                                                                                                                                                                                                                                                             |
 | `CI_PAGES_URL`                                | 11.8   | all    | URL to GitLab Pages-built pages. Always belongs to a subdomain of `CI_PAGES_DOMAIN`.                                                                                                                                                                                                                                                                       |
-| `CI_PIPELINE_ID`                              | 8.10   | all    | The unique id of the current pipeline that GitLab CI uses internally                                                                                                                                                                                                                                                                                       |
+| `CI_PIPELINE_ID`                              | 8.10   | all    | The unique id of the current pipeline that GitLab CI/CD uses internally                                                                                                                                                                                                                                                                                       |
 | `CI_PIPELINE_IID`                             | 11.0   | all    | The unique id of the current pipeline scoped to project                                                                                                                                                                                                                                                                                                    |
 | `CI_PIPELINE_SOURCE`                          | 10.0   | all    | Indicates how the pipeline was triggered. Possible options are: `push`, `web`, `trigger`, `schedule`, `api`, `pipeline`, `external`, `chat`, `merge_request_event`, and `external_pull_request_event`. For pipelines created before GitLab 9.5, this will show as `unknown`                                                                                                                                                          |
 | `CI_PIPELINE_TRIGGERED`                       | all    | all    | The flag to indicate that job was [triggered](../triggers/README.md)                                                                                                                                                                                                                                                                                       |
 | `CI_PIPELINE_URL`                             | 11.1   | 0.5    | Pipeline details URL                                                                                                                                                                                                                                                                                                                                       |
 | `CI_PROJECT_DIR`                              | all    | all    | The full path where the repository is cloned and where the job is run. If the GitLab Runner `builds_dir` parameter is set, this variable is set relative to the value of `builds_dir`. For more information, see [Advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) for GitLab Runner. |
-| `CI_PROJECT_ID`                               | all    | all    | The unique id of the current project that GitLab CI uses internally                                                                                                                                                                                                                                                                                        |
+| `CI_PROJECT_ID`                               | all    | all    | The unique id of the current project that GitLab CI/CD uses internally                                                                                                                                                                                                                                                                                        |
 | `CI_PROJECT_NAME`                             | 8.10   | 0.5    | The name of the directory for the project that is currently being built. For example, if the project URL is `gitlab.example.com/group-name/project-1`, the `CI_PROJECT_NAME` would be `project-1`.                                                                                                                                                         |
 | `CI_PROJECT_NAMESPACE`                        | 8.10   | 0.5    | The project namespace (username or groupname) that is currently being built                                                                                                                                                                                                                                                                                |
 | `CI_PROJECT_PATH`                             | 8.10   | 0.5    | The namespace with project name                                                                                                                                                                                                                                                                                                                            |
@@ -127,7 +127,7 @@ future GitLab releases.**
 | `CI_SERVER_VERSION_PATCH`                     | 11.4   | all    | GitLab version patch component                                                                                                                                                                                                                                                                                                                             |
 | `CI_SHARED_ENVIRONMENT`                       | all    | 10.1   | Marks that the job is executed in a shared environment (something that is persisted across CI invocations like `shell` or `ssh` executor). If the environment is shared, it is set to true, otherwise it is not defined at all.                                                                                                                            |
 | `GET_SOURCES_ATTEMPTS`                        | 8.15   | 1.9    | Number of attempts to fetch sources running a job                                                                                                                                                                                                                                                                                                          |
-| `GITLAB_CI`                                   | all    | all    | Mark that job is executed in GitLab CI environment                                                                                                                                                                                                                                                                                                         |
+| `GITLAB_CI`                                   | all    | all    | Mark that job is executed in GitLab CI/CD environment                                                                                                                                                                                                                                                                                                         |
 | `GITLAB_FEATURES`                             | 10.6   | all    | The comma separated list of licensed features available for your instance and plan                                                                                                                                                                                                                                                                         |
 | `GITLAB_USER_EMAIL`                           | 8.12   | all    | The email of the user who started the job                                                                                                                                                                                                                                                                                                                  |
 | `GITLAB_USER_ID`                              | 8.12   | all    | The id of the user who started the job                                                                                                                                                                                                                                                                                                                     |

doc/ci/yaml/README.md

@@ -18,7 +18,7 @@ This topic covers CI/CD pipeline configuration. For other CI/CD configuration in
 
 We have complete examples of configuring pipelines:
 
-- For a quick introduction to GitLab CI, follow our [quick start guide](../quick_start/README.md).
+- For a quick introduction to GitLab CI/CD, follow our [quick start guide](../quick_start/README.md).
 - For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
 - To see a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
@@ -58,7 +58,7 @@ independently from each other.
 
 ### Validate the `.gitlab-ci.yml`
 
-Each instance of GitLab CI has an embedded debug tool called Lint, which validates the
+Each instance of GitLab CI/CD has an embedded debug tool called Lint, which validates the
 content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your
 project namespace. For example, `https://gitlab.example.com/gitlab-org/project-123/-/ci/lint`.
 
@@ -312,7 +312,7 @@ For:
 
 - Simple definition examples, see [Define `image` and `services` from `.gitlab-ci.yml`](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml).
 - Detailed usage information, refer to [Docker integration](../docker/README.md) documentation.
-- For example services, see [GitLab CI Services](../services/README.md).
+- For example services, see [GitLab CI/CD Services](../services/README.md).
 
 #### `services:name`
 
@@ -3958,7 +3958,7 @@ lines where the job is defined:
 ```
 
 you can instead start its name with a dot (`.`) and it will not be processed by
-GitLab CI. In the following example, `.hidden_job` will be ignored:
+GitLab CI/CD. In the following example, `.hidden_job` will be ignored:
 
 ```yaml
 .hidden_job:

doc/development/architecture.md

@@ -150,7 +150,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Mattermost](#mattermost) | Open-source Slack alternative | [⚙][mattermost-omnibus] | [⤓][mattermost-charts] | [⤓][mattermost-charts] | [⤓](../user/project/integrations/mattermost.md) | ❌ | ❌ | CE & EE |
 | [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE |
-| [Runner](#gitlab-runner) | Executes GitLab CI jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE |
+| [Runner](#gitlab-runner) | Executes GitLab CI/CD jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE |
 | [Database Migrations](#database-migrations) | Database migrations | [✅][database-migrations-omnibus] | [✅][database-migrations-charts] | [✅][database-migrations-charts] | ✅ | [⚙][database-migrations-source] | ✅ | CE & EE |
 | [Certificate Management](#certificate-management) | TLS Settings, Let's Encrypt | [✅][certificate-management-omnibus] | [✅][certificate-management-charts] | [⚙][certificate-management-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management) | [⚙][certificate-management-source] | [⚙][certificate-management-gdk] | CE & EE |
 | [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | [⚙][geo-omnibus] | [❌][geo-charts] | [❌][geo-charts] | ✅ | ❌ | [⚙][geo-gdk] | EE Only |
@@ -263,7 +263,7 @@ You can use it either for personal or business websites, such as portfolios, doc
 
 GitLab Runner runs tests and sends the results to GitLab.
 
-GitLab CI is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was GitLab CI Multi Runner but please use "GitLab Runner" (without CI) from now on.
+GitLab CI/CD is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was `GitLab CI Multi Runner` but please use `GitLab Runner` (without CI) from now on.
 
 #### GitLab Shell
 

doc/development/auto_devops.md

@@ -5,7 +5,7 @@ This document provides a development guide for contributors to
 
 ## Development
 
-Auto DevOps builds on top of GitLab CI to create an automatic pipeline
+Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline
 based on your project contents. When Auto DevOps is enabled for a
 project, the user does not need to explicitly include any pipeline configuration
 through a [`.gitlab-ci.yml` file](../ci/yaml/README.md).

doc/development/dangerbot.md

 # Danger bot
 
-The GitLab CI pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger)
+The GitLab CI/CD pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger)
 to perform a variety of automated checks on the code under test.
 
 Danger is a gem that runs in the CI environment, like any other analysis tool.

doc/development/fe_guide/style/scss.md

@@ -245,7 +245,7 @@ ruleset in `.scss-lint.yml`, which is located in the home directory of the
 project.
 
 To check if any warnings will be produced by your changes, you can run `rake
-scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI to
+scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI/CD to
 catch any warnings.
 
 If the Rake task is throwing warnings you don't understand, SCSS Lint's

doc/development/integrations/secure.md

@@ -170,7 +170,7 @@ it is recommended to expose configuration as environment variables, not files.
 
 ### Output file
 
-Like any artifact uploaded to the GitLab CI,
+Like any artifact uploaded to the GitLab CI/CD,
 the Secure report generated by the scanner must be written in the project directory,
 given by the `CI_PROJECT_DIR` environment variable.
 

doc/development/merge_request_performance_guidelines.md

@@ -377,7 +377,7 @@ Examples:
    in service degradation as the system will try to process all schedules
    assigned the the project.
 
-1. GitLab CI includes: We started with the limit of maximum of 50 nested includes.
+1. GitLab CI/CD includes: We started with the limit of maximum of 50 nested includes.
    We understood that performance of the feature was acceptable at that level.
    We received a request from the community that the limit is too small.
    We had a time to understand the customer requirement, and implement an additional

doc/integration/jenkins.md

@@ -13,7 +13,7 @@ document.
 ## Overview
 
 [Jenkins](https://jenkins.io/) is a great Continuous Integration tool, similar to our built-in
-[GitLab CI](../ci/README.md).
+[GitLab CI/CD](../ci/README.md).
 
 GitLab's Jenkins integration allows you to trigger a Jenkins build when you
 push code to a repository, or when a merge request is created. Additionally,
@@ -26,7 +26,7 @@ and [Migrating from Jenkins to GitLab](https://www.youtube.com/watch?v=RlEVGOpYF
 
 - Suppose you are new to GitLab, and want to keep using Jenkins until you prepare
   your projects to build with [GitLab CI/CD](../ci/README.md). You set up the
-  integration between GitLab and Jenkins, then you migrate to GitLab CI later. While
+  integration between GitLab and Jenkins, then you migrate to GitLab CI/CD later. While
   you organize yourself and your team to onboard GitLab, you keep your pipelines
   running with Jenkins, but view the results in your project's repository in GitLab.
 - Your team uses [Jenkins Plugins](https://plugins.jenkins.io/) for other proceedings,

doc/intro/README.md

@@ -35,7 +35,7 @@ Create merge requests and review code.
 
 Use the built-in continuous integration in GitLab.
 
-- [Get started with GitLab CI](../ci/quick_start/README.md)
+- [Get started with GitLab CI/CD](../ci/quick_start/README.md)
 
 ## Install and Update
 

doc/push_rules/push_rules.md

@@ -40,7 +40,7 @@ will be accepted.
 
 Let's assume there's a strict policy for branch names in your company, and
 you want the branches to start with a certain name because you have different
-GitLab CI jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the
+GitLab CI/CD jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the
 branch name.
 
 Your developers however, don't always remember that policy, so they push

doc/topics/autodevops/index.md

@@ -799,7 +799,7 @@ networkPolicy:
 ```
 
 For more information on how to install Network Policies, see
-[Install Cilium using GitLab CI](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd).
+[Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd).
 
 #### Web Application Firewall (ModSecurity) customization
 

doc/topics/gitlab_flow.md

@@ -309,7 +309,7 @@ In old workflows, the continuous integration (CI) server commonly ran tests on t
 Developers had to ensure their code did not break the `master` branch.
 When using GitLab flow, developers create their branches from this `master` branch, so it is essential that it never breaks.
 Therefore, each merge request must be tested before it is accepted.
-CI software like Travis CI and GitLab CI show the build results right in the merge request itself to make this easy.
+CI software like Travis CI and GitLab CI/CD show the build results right in the merge request itself to make this easy.
 
 There is one drawback to testing merge requests: the CI server only tests the feature branch itself, not the merged result.
 Ideally, the server could also test the `master` branch after each change.

doc/topics/index.md

@@ -9,7 +9,7 @@ tutorials, technical overviews, blog posts) and videos.
 
 - [Auto DevOps](autodevops/index.md)
 - [Authentication](authentication/index.md)
-- [Continuous Integration (GitLab CI)](../ci/README.md)
+- [Continuous Integration (GitLab CI/CD)](../ci/README.md)
 - [Git](git/index.md)
 - [GitLab Flow](gitlab_flow.md)
 - [GitLab Installation](../install/README.md)

doc/university/README.md

@@ -107,7 +107,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 ### 2.3. Continuous Integration
 
 1. [Operating Systems, Servers, VMs, Containers and Unix - Video](https://www.youtube.com/watch?v=V61kL6IC-zY&index=8&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)
-1. [GitLab CI - Product Page](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/)
+1. [GitLab CI/CD - Product Page](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/)
 1. [Getting started with GitLab and GitLab CI](https://about.gitlab.com/blog/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/)
 1. [GitLab Container Registry](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/)
 1. [GitLab and Docker - Video](https://www.youtube.com/watch?v=ugOrCcbdHko&index=12&list=PLFGfElNsQthbQu_IWlNOxul0TbS_2JH-e)

doc/university/support/README.md

@@ -173,7 +173,7 @@ Move on to understanding some of GitLab's more advanced features. You can make u
 - Set up and try [Git LFS](../../administration/lfs/manage_large_binaries_with_git_lfs.md)
 - Get to know the [GitLab API](../../api/README.md), its capabilities and shortcomings
 - Learn how to [migrate from SVN to Git](../../user/project/import/svn.md)
-- Set up [GitLab CI](../../ci/quick_start/README.md)
+- Set up [GitLab CI/CD](../../ci/quick_start/README.md)
 - Create your first [GitLab Page](../../administration/pages/index.md)
 - Get to know the GitLab Codebase by reading through the source code:
   - Find the differences between the [EE codebase](https://gitlab.com/gitlab-org/gitlab-foss)

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:

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)

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

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

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:

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

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
 

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

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

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

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/)

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

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

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.

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: