Remove more references to master in CI docs

doc/api/job_artifacts.md

@@ -90,7 +90,7 @@ Parameters
 Example request using the `PRIVATE-TOKEN` header:
 
 ```shell
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test"
+curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test"
 ```
 
 To use this in a [`script` definition](../ci/yaml/README.md#script) inside
@@ -98,25 +98,25 @@ To use this in a [`script` definition](../ci/yaml/README.md#script) inside
 
 - The `JOB-TOKEN` header with the GitLab-provided `CI_JOB_TOKEN` variable.
   For example, the following job downloads the artifacts of the `test` job
-  of the `master` branch. Note that the command is wrapped into single quotes
+  of the `main` branch. Note that the command is wrapped into single quotes
   because it contains a colon (`:`):
 
   ```yaml
   artifact_download:
     stage: test
     script:
-      - 'curl --location --output artifacts.zip --header "JOB-TOKEN: $CI_JOB_TOKEN" "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/jobs/artifacts/master/download?job=test"'
+      - 'curl --location --output artifacts.zip --header "JOB-TOKEN: $CI_JOB_TOKEN" "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/jobs/artifacts/main/download?job=test"'
   ```
 
 - Or the `job_token` attribute with the GitLab-provided `CI_JOB_TOKEN` variable.
   For example, the following job downloads the artifacts of the `test` job
-  of the `master` branch:
+  of the `main` branch:
 
   ```yaml
   artifact_download:
     stage: test
     script:
-      - 'curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"'
+      - 'curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"'
   ```
 
 Possible response status codes:
@@ -193,7 +193,7 @@ Parameters:
 Example request:
 
 ```shell
-curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/raw/some/release/file.pdf?job=pdf"
+curl --location --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/raw/some/release/file.pdf?job=pdf"
 ```
 
 Possible response status codes:
@@ -243,7 +243,7 @@ Example response:
   "download_url": null,
   "id": 42,
   "name": "rubocop",
-  "ref": "master",
+  "ref": "main",
   "artifacts": [],
   "runner": null,
   "stage": "test",

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -59,8 +59,7 @@ to run. If more merge requests are added to the train, they now include the `A`
 changes that are included in the target branch, and the `C` changes that are from
 the merge request already in the train.
 
-Read more about
-[how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
+Read more about [how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 Watch this video for a demonstration on [how parallel execution

doc/ci/multi_project_pipelines.md

@@ -271,7 +271,7 @@ trigger_job:
 ### Mirroring status from upstream pipeline
 
 You can mirror the pipeline status from an upstream pipeline to a bridge job by
-using the `needs:pipeline` keyword. The latest pipeline status from master is
+using the `needs:pipeline` keyword. The latest pipeline status from the default branch is
 replicated to the bridge job.
 
 Example:

doc/ci/triggers/README.md

@@ -140,21 +140,21 @@ By using cURL you can trigger a pipeline rerun with minimal effort, for example:
 ```shell
 curl --request POST \
      --form token=TOKEN \
-     --form ref=master \
+     --form ref=main \
      "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
-In this case, the pipeline for the project with ID `9` runs on the `master` branch.
+In this case, the pipeline for the project with ID `9` runs on the `main` branch.
 
 Alternatively, you can pass the `token` and `ref` arguments in the query string:
 
 ```shell
 curl --request POST \
-    "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=master"
+    "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=main"
 ```
 
 You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
-you have two projects, A and B, and you want to trigger a pipeline on the `master`
+you have two projects, A and B, and you want to trigger a pipeline on the `main`
 branch of project B whenever a tag on project A is created. This is the job you
 need to add in project A's `.gitlab-ci.yml`:
 
@@ -162,7 +162,7 @@ need to add in project A's `.gitlab-ci.yml`:
 trigger_pipeline:
   stage: deploy
   script:
-    - 'curl --request POST --form token=TOKEN --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"'
+    - 'curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"'
   only:
     - tags
 ```
@@ -261,11 +261,11 @@ of all types of variables.
 ## Using cron to trigger nightly pipelines
 
 Whether you craft a script or just run cURL directly, you can trigger jobs
-in conjunction with cron. The example below triggers a job on the `master`
+in conjunction with cron. The example below triggers a job on the `main` branch
 branch of project with ID `9` every night at `00:30`:
 
 ```shell
-30 0 * * * curl --request POST --form token=TOKEN --form ref=master "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+30 0 * * * curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
 This behavior can also be achieved through the GitLab UI with

doc/ci/yaml/README.md

@@ -253,7 +253,7 @@ variables:
 
 workflow:
   rules:
-    - if: $CI_COMMIT_REF_NAME =~ /master/
+    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
       variables:
         DEPLOY_VARIABLE: "deploy-production"  # Override globally-defined DEPLOY_VARIABLE
     - if: $CI_COMMIT_REF_NAME =~ /feature/
@@ -265,7 +265,7 @@ job1:
   variables:
     DEPLOY_VARIABLE: "job1-default-deploy"
   rules:
-    - if: $CI_COMMIT_REF_NAME =~ /master/
+    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
       variables:                                   # Override DEPLOY_VARIABLE defined
         DEPLOY_VARIABLE: "job1-deploy-production"  # at the job level.
     - when: on_success                             # Run the job in other cases
@@ -279,7 +279,7 @@ job2:
     - echo "Run another script if $IS_A_FEATURE exists"
 ```
 
-When the branch is `master`:
+When the branch is the default branch:
 
 - job1's `DEPLOY_VARIABLE` is `job1-deploy-production`.
 - job2's `DEPLOY_VARIABLE` is `deploy-production`.
@@ -559,7 +559,7 @@ You can also specify a `ref`. If you do not specify a value, the ref defaults to
 ```yaml
 include:
   - project: 'my-group/my-project'
-    ref: master
+    ref: main
     file: '/templates/.gitlab-ci-template.yml'
 
   - project: 'my-group/my-project'
@@ -584,7 +584,7 @@ You can include multiple files from the same project:
 ```yaml
 include:
   - project: 'my-group/my-project'
-    ref: master
+    ref: main
     file:
       - '/templates/.builds.yml'
       - '/templates/.tests.yml'
@@ -598,7 +598,7 @@ authentication in the remote URL is not supported. For example:
 
 ```yaml
 include:
-  - remote: 'https://gitlab.com/example-project/-/raw/master/.gitlab-ci.yml'
+  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
 ```
 
 All [nested includes](#nested-includes) execute without context as a public user,
@@ -1137,7 +1137,7 @@ For example:
 docker build:
   script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
   rules:
-    - if: '$CI_COMMIT_BRANCH == "master"'
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
       when: delayed
       start_in: '3 hours'
       allow_failure: true
@@ -1335,7 +1335,7 @@ For example:
 job:
   script: echo "Hello, Rules!"
   rules:
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
+    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH'
       when: always
     - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/'
       when: manual
@@ -1533,7 +1533,7 @@ the particular rule triggers the job.
 job:
   script: echo "Hello, Rules!"
   rules:
-    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
+    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH'
       when: manual
       allow_failure: true
 ```
@@ -1554,7 +1554,7 @@ job:
   variables:
     DEPLOY_VARIABLE: "default-deploy"
   rules:
-    - if: $CI_COMMIT_REF_NAME =~ /master/
+    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
       variables:                              # Override DEPLOY_VARIABLE defined
         DEPLOY_VARIABLE: "deploy-production"  # at the job level.
     - if: $CI_COMMIT_REF_NAME =~ /feature/
@@ -1602,7 +1602,7 @@ job1:
   script:
     - echo This rule uses parentheses.
   rules:
-    if: ($CI_COMMIT_BRANCH == "master" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
+    if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE
 ```
 
 WARNING:
@@ -1968,12 +1968,12 @@ build_job:
   needs:
     - project: namespace/group/project-name
       job: build-1
-      ref: master
+      ref: main
       artifacts: true
 ```
 
 `build_job` downloads the artifacts from the latest successful `build-1` job
-on the `master` branch in the `group/project-name` project. If the project is in the
+on the `main` branch in the `group/project-name` project. If the project is in the
 same group or namespace, you can omit them from the `project:` keyword. For example,
 `project: group/project-name` or `project: project-name`.
 
@@ -2091,9 +2091,9 @@ error similar to:
 
 In this example:
 
-- When the branch is `master`, the `build` job exists in the pipeline, and the `rspec`
+- When the branch is the default branch, the `build` job exists in the pipeline, and the `rspec`
   job waits for it to complete before starting.
-- When the branch is not `master`, the `build` job does not exist in the pipeline.
+- When the branch is not the default branch, the `build` job does not exist in the pipeline.
   The `rspec` job runs immediately (similar to `needs: []`) because its `needs`
   relationship to the `build` job is optional.
 
@@ -2101,7 +2101,7 @@ In this example:
 build:
   stage: build
   rules:
-    - if: $CI_COMMIT_REF_NAME == "master"
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
 
 rspec:
   stage: test
@@ -2356,7 +2356,7 @@ To protect a manual job:
        url: https://example.com
      when: manual
      only:
-       - master
+       - main
    ```
 
 1. In the [protected environments settings](../environments/protected_environments.md#protecting-environments),
@@ -4065,7 +4065,7 @@ child-pipeline:
   trigger:
     include:
       - project: 'my-group/my-pipeline-library'
-        ref: 'master'
+        ref: 'main'
         file: '/path/to/child-pipeline.yml'
 ```
 
@@ -4664,7 +4664,7 @@ pages:
     paths:
       - public
   only:
-    - master
+    - main
 ```
 
 View the [GitLab Pages user documentation](../../user/project/pages/index.md).