Merge branch 'docs-ci-gitlab-s' into 'master'

Remove incorrect usage of GitLab's in CI docs

See merge request gitlab-org/gitlab!49714

doc/api/merge_trains.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Merge Trains API **(PREMIUM)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36146) in GitLab 12.9.
-> - Using this API you can consume GitLab's [Merge Train](../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md) entries.
+> - Using this API you can consume [Merge Train](../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md) entries.
 
 Every API call to merge trains must be authenticated with Developer or higher [permissions](../user/permissions.md).
 

doc/ci/caching/index.md

@@ -541,7 +541,7 @@ next run of the pipeline, the cache is stored in a different location.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41249) in GitLab 10.4.
 
 If you want to avoid editing `.gitlab-ci.yml`, you can clear the cache
-via GitLab's UI:
+via the GitLab UI:
 
 1. Navigate to your project's **CI/CD > Pipelines** page.
 1. Click on the **Clear runner caches** button to clean up the cache.

doc/ci/examples/authenticating-with-hashicorp-vault/index.md

@@ -152,7 +152,7 @@ EOF
 
 This example uses [bound_claims](https://www.vaultproject.io/api/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims will be allowed to authenticate.
 
-Combined with GitLab's [protected branches](../../../user/project/protected_branches.md), you can restrict who is able to authenticate and read the secrets.
+Combined with [protected branches](../../../user/project/protected_branches.md), you can restrict who is able to authenticate and read the secrets.
 
 [token_explicit_max_ttl](https://www.vaultproject.io/api/auth/jwt#token_explicit_max_ttl) specifies that the token issued by Vault, upon successful authentication, has a hard lifetime limit of 60 seconds.
 

doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md

@@ -431,7 +431,7 @@ fully understand [IAM Best Practices in AWS](https://docs.aws.amazon.com/IAM/lat
 To deploy our build artifacts, we need to install the [AWS CLI](https://aws.amazon.com/cli/) on
 the shared runner. The shared runner also needs to be able to authenticate with your AWS
 account to deploy the artifacts. By convention, AWS CLI will look for `AWS_ACCESS_KEY_ID`
-and `AWS_SECRET_ACCESS_KEY`. GitLab's CI gives us a way to pass the variables we
+and `AWS_SECRET_ACCESS_KEY`. GitLab CI/CD gives us a way to pass the variables we
 set up in the prior section using the `variables` portion of the `deploy` job. At the end,
 we add directives to ensure deployment `only` happens on pushes to `master`. This way, every
 single branch still runs through CI, and only merging (or committing directly) to master will
@@ -509,7 +509,7 @@ Within the [demo repository](https://gitlab.com/blitzgren/gitlab-game-demo) you
 together nicely with GitLab CI/CD, which is the result of lessons learned while making [Dark Nova](https://www.darknova.io).
 Using a combination of free and open source software, we have a full CI/CD pipeline, a game foundation,
 and unit tests, all running and deployed at every push to master - with shockingly little code.
-Errors can be easily debugged through GitLab's build logs, and within minutes of a successful commit,
+Errors can be easily debugged through GitLab build logs, and within minutes of a successful commit,
 you can see the changes live on your game.
 
 Setting up Continuous Integration and Continuous Deployment from the start with Dark Nova enables

doc/ci/introduction/index.md

@@ -116,7 +116,7 @@ After you're happy with your implementation:
 ![GitLab workflow example](img/gitlab_workflow_example_11_9.png)
 
 GitLab CI/CD is capable of doing a lot more, but this workflow
-exemplifies GitLab's ability to track the entire process,
+exemplifies the ability of GitLab to track the entire process,
 without the need for an external tool to deliver your software.
 And, most usefully, you can visualize all the steps through
 the GitLab UI.

doc/ci/pipelines/job_artifacts.md

@@ -58,7 +58,7 @@ For more examples on artifacts, follow the [artifacts reference in
 > - Requires GitLab Runner 11.2 and above.
 
 The `artifacts:reports` keyword is used for collecting test reports, code quality
-reports, and security reports from jobs. It also exposes these reports in GitLab's
+reports, and security reports from jobs. It also exposes these reports in the GitLab
 UI (merge requests, pipeline views, and security dashboards).
 
 The test reports are collected regardless of the job results (success or failure).

doc/ci/pipelines/settings.md

@@ -26,7 +26,7 @@ There are two options. Using:
 
 - `git clone`, which is slower since it clones the repository from scratch
   for every job, ensuring that the local working copy is always pristine.
-- `git fetch`, which is GitLab's default and faster as it re-uses the local working copy (falling
+- `git fetch`, which is default in GitLab and faster as it re-uses the local working copy (falling
   back to clone if it doesn't exist).
   This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
 

doc/ci/triggers/README.md

@@ -114,7 +114,7 @@ The action is irreversible.
 
 ## Triggering a pipeline
 
-To trigger a job you need to send a `POST` request to GitLab's API endpoint:
+To trigger a job you need to send a `POST` request to the GitLab API endpoint:
 
 ```plaintext
 POST /projects/:id/trigger/pipeline
@@ -126,7 +126,7 @@ branches or tags. The `:id` of a project can be found by
 [querying the API](../../api/projects.md) or by visiting the **CI/CD**
 settings page which provides self-explanatory examples.
 
-When a rerun of a pipeline is triggered, the information is exposed in GitLab's
+When a rerun of a pipeline is triggered, the information is exposed in the GitLab
 UI under the **Jobs** page and the jobs are marked as triggered 'by API'.
 
 ![Marked rebuilds as on jobs page](img/builds_page.png)
@@ -260,7 +260,7 @@ branch of project with ID `9` every night at `00:30`:
 30 0 * * * curl --request POST --form token=TOKEN --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
-This behavior can also be achieved through GitLab's UI with
+This behavior can also be achieved through the GitLab UI with
 [pipeline schedules](../pipelines/schedules.md).
 
 ## Legacy triggers

doc/ci/variables/README.md

@@ -415,7 +415,7 @@ You can define per-project or per-group variables that are set in the pipeline e
 We recommend using group environment variables to store secrets (like passwords, SSH keys, and credentials) for Premium users who:
 
 - Do **not** use an external key store.
-- Use GitLab's [integration with HashiCorp Vault](../secrets/index.md).
+- Use the GitLab [integration with HashiCorp Vault](../secrets/index.md).
 
 Group-level variables can be added by:
 

doc/ci/variables/predefined_variables.md

@@ -118,7 +118,7 @@ Kubernetes-specific environment variables are detailed in the
 | `CI_PROJECT_TITLE`                            | 12.4   | all    | The human-readable project name as displayed in the GitLab web interface.                                                                                                                                                                                                                                                                                  |
 | `CI_PROJECT_URL`                              | 8.10   | 0.5    | The HTTP(S) address to access project                                                                                                                                                                                                                                                                                                                      |
 | `CI_PROJECT_VISIBILITY`                       | 10.3   | all    | The project visibility (internal, private, public)                                                                                                                                                                                                                                                                                                         |
-| `CI_REGISTRY`                                 | 8.10   | 0.5    | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable includes a `:port` value if one has been specified in the registry configuration.                                                                                                                                                           |
+| `CI_REGISTRY`                                 | 8.10   | 0.5    | If the Container Registry is enabled it returns the address of the GitLab Container Registry. This variable includes a `:port` value if one has been specified in the registry configuration.                                                                                                                                                           |
 | `CI_REGISTRY_IMAGE`                           | 8.10   | 0.5    | If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project                                                                                                                                                                                                                                   |
 | `CI_REGISTRY_PASSWORD`                        | 9.0    | all    | The password to use to push containers to the GitLab Container Registry, for the current project.                                                                                                                                                                                                                                                                |
 | `CI_REGISTRY_USER`                            | 9.0    | all    | The username to use to push containers to the GitLab Container Registry, for the current project.                                                                                                                                                                                                                                                                 |

doc/ci/variables/where_variables_can_be_used.md

@@ -24,7 +24,7 @@ There are two places defined variables can be used. On the:
 
 | Definition                                 | Can be expanded? | Expansion place        | Description                                                                                                                                                                                                                                                                                                                                                                                                                       |
 |:-------------------------------------------|:-----------------|:-----------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `environment:url`                          | yes              | GitLab                 | The variable expansion is made by GitLab's [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism).<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
+| `environment:url`                          | yes              | GitLab                 | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
 | `environment:name`                         | yes              | GitLab                 | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables).                                                                                 |
 | `resource_group`                           | yes              | GitLab                 | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables).                                                                                 |
 | `variables`                                | yes              | Runner                 | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism)                                                                                                                                                                                                                                                                                   |

doc/ci/yaml/README.md

@@ -503,7 +503,7 @@ so you can only `include` public projects or templates.
 For example:
 
 ```yaml
-# File sourced from GitLab's template collection
+# File sourced from the GitLab template collection
 include:
   - template: Auto-DevOps.gitlab-ci.yml
 ```
@@ -2472,7 +2472,7 @@ environment. A new `stop_review_app` job is listed under `on_stop`.
 After the `review_app` job is finished, it triggers the
 `stop_review_app` job based on what is defined under `when`. In this case,
 it is set to `manual`, so it needs a [manual action](#whenmanual) from
-GitLab's user interface to run.
+the GitLab UI to run.
 
 Also in the example, `GIT_STRATEGY` is set to `none`. If the
 `stop_review_app` job is [automatically triggered](../environments/index.md#automatically-stopping-an-environment),
@@ -3174,7 +3174,7 @@ in GitLab 13.4.
 
 The [`artifacts:reports` keyword](../pipelines/job_artifacts.md#artifactsreports)
 is used for collecting test reports, code quality reports, and security reports from jobs.
-It also exposes these reports in GitLab's UI (merge requests, pipeline views, and security dashboards).
+It also exposes these reports in the GitLab UI (merge requests, pipeline views, and security dashboards).
 
 These are the available report types:
 

doc/development/documentation/site_architecture/global_nav.md

@@ -101,11 +101,11 @@ The global nav has 3 components:
 
 The available sections are described on the table below:
 
-| Section       | Description                                |
-| ------------- | ------------------------------------------ |
-| User          | Documentation for the GitLab's user UI.    |
-| Administrator | Documentation for the GitLab's Admin Area. |
-| Contributor   | Documentation for developing GitLab.       |
+| Section       | Description                          |
+| ------------- | ------------------------------------ |
+| User          | Documentation for the GitLab UI.     |
+| Administrator | Documentation for the Admin Area.    |
+| Contributor   | Documentation for developing GitLab. |
 
 The majority of the links available on the nav were added according to the UI.
 The match is not perfect, as for some UI nav items the documentation doesn't
@@ -250,7 +250,7 @@ below the doc link:
 ```
 
 All nav links are clickable. If the higher-level link does not have a link
-of its own, it must link to its first sub-item link, mimicking GitLab's navigation.
+of its own, it must link to its first sub-item link, mimicking the navigation in GitLab.
 This must be avoided so that we don't have duplicated links nor two `.active` links
 at the same time.
 

doc/development/documentation/site_architecture/index.md

@@ -2,7 +2,6 @@
 stage: none
 group: unassigned
 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
-description: "Learn how GitLab's documentation website is architectured."
 ---
 
 # Documentation site architecture
@@ -14,8 +13,8 @@ static site generator.
 
 ## Architecture
 
-While the source of the documentation content is stored in GitLab's respective product
-repositories, the source that is used to build the documentation
+While the source of the documentation content is stored in the repositories for
+each GitLab product, the source that is used to build the documentation
 site _from that content_ is located at <https://gitlab.com/gitlab-org/gitlab-docs>.
 
 The following diagram illustrates the relationship between the repositories

doc/development/documentation/structure.md

@@ -9,7 +9,7 @@ description: What to include in GitLab documentation pages.
 
 Use these standards to contribute content to the GitLab documentation.
 
-Before getting started, familiarize yourself with [GitLab's Documentation guidelines](index.md)
+Before getting started, familiarize yourself with [Documentation guidelines for GitLab](index.md)
 and the [Documentation Style Guide](styleguide/index.md).
 
 ## Components of a documentation page

doc/development/documentation/testing.md

@@ -31,8 +31,8 @@ run these tests on your local computer. This has the advantage of:
 
 - Speeding up the feedback loop. You can know of any problems with the changes in your branch
   without waiting for a CI/CD pipeline to run.
-- Lowering costs. Running tests locally is cheaper than running tests on GitLab's cloud
-  infrastructure.
+- Lowering costs. Running tests locally is cheaper than running tests on the cloud
+  infrastructure GitLab uses.
 
 To run tests locally, it's important to:
 
@@ -106,9 +106,9 @@ To run the `ui-docs-links` test locally:
    ```
 
 If you receive an error the first time you run this test, run `bundle install`, which
-installs GitLab's dependencies, and try again.
+installs the dependencies for GitLab, and try again.
 
-If you don't want to install all of GitLab's dependencies to test the links, you can:
+If you don't want to install all of the dependencies to test the links, you can:
 
 1. Open the `gitlab` directory in a terminal window.
 1. Install `haml-lint`:

doc/development/documentation/workflow.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Documentation process
 
 The process for creating and maintaining GitLab product documentation allows
-anyone to contribute a merge request or create an issue for GitLab's
+anyone to contribute a merge request or create an issue for GitLab
 documentation.
 
 Documentation updates relating to new features or feature enhancements must
@@ -60,7 +60,7 @@ To update GitLab documentation:
    - The [Structure and template](structure.md) page.
    - The [Style Guide](styleguide/index.md).
    - The [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/).
-1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
+1. Follow the [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 NOTE:
 Work in a fork if you do not have Developer access to the GitLab project.
@@ -79,7 +79,7 @@ To request help:
    - If urgent help is required, directly assign the Technical Writer in the issue or in the merge request.
    - If non-urgent help is required, ping the Technical Writer in the issue or merge request.
 
-If you are a member of GitLab's Slack workspace, you can request help in `#docs`.
+If you are a member of the GitLab Slack workspace, you can request help in `#docs`.
 
 ### Reviewing and merging
 

doc/user/project/new_ci_build_permissions_model.md

@@ -203,18 +203,17 @@ To properly configure submodules with GitLab CI/CD, read the
 With the update permission model we also extended the support for accessing
 Container Registries for private projects.
 
-> **Notes:**
->
-> - GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
->   for permissions. This makes the `image:` directive not work with private
->   projects automatically and it needs to be configured manually on the GitLab Runner host
->   with a predefined account (for example administrator's personal account with
->   access token created explicitly for this purpose). This issue is resolved with
->   latest changes in GitLab Runner 1.8 which receives GitLab credentials with
->   build data.
-> - Starting from GitLab 8.12, if you have [2FA](../profile/account/two_factor_authentication.md) enabled in your account, you need
->   to pass a [personal access token](../profile/personal_access_tokens.md) instead of your password in order to
->   login to GitLab's Container Registry.
+GitLab Runner versions prior to 1.8 don't incorporate the introduced changes
+for permissions. This makes the `image:` directive not work with private
+projects automatically and it needs to be configured manually on the GitLab Runner host
+with a predefined account (for example administrator's personal account with
+access token created explicitly for this purpose). This issue is resolved with
+latest changes in GitLab Runner 1.8 which receives GitLab credentials with
+build data.
+
+Starting from GitLab 8.12, if you have [2FA](../profile/account/two_factor_authentication.md) enabled in your account, you need
+to pass a [personal access token](../profile/personal_access_tokens.md) instead of your password in order to
+login to the Container Registry.
 
 Your jobs can access all container images that you would normally have access
 to. The only implication is that you can push to the Container Registry of the