Add latest changes from gitlab-org/gitlab@master

14 files changed, 69 insertions, 78 deletions

diff --git a/doc/.vale/gitlab/DefaultBranch.yml b/doc/.vale/gitlab/DefaultBranch.yml
new file mode 100644
index 00000000000..4bc68433c6d
--- /dev/null
+++ b/doc/.vale/gitlab/DefaultBranch.yml
@@ -0,0 +1,14 @@
+---
+# Warning: gitlab.DefaultBranch
+#
+# Do not refer to the default branch as the "master" branch, if possible.
+#
+# For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
+extends: existence
+message: 'Use "default branch" or `main` instead of `master`, when possible.'
+level: warning
+ignorecase: true
+link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html
+scope: raw
+raw:
+  - '\`master\`'
diff --git a/doc/api/repositories.md b/doc/api/repositories.md
index 649fe0cce8b..49a53039847 100644
--- a/doc/api/repositories.md
+++ b/doc/api/repositories.md
@@ -337,38 +337,41 @@ attribute.
 
 ### Examples
 
-For these examples we use the project ID 42, and assume the project is hosted on
-GitLab.com. The example API token we use is `token`. We use
-[curl](https://curl.se/) to perform the HTTP requests.
+These examples use [cURL](https://curl.se/) to perform HTTP requests.
+The example commands use these values:
 
-Let's start with a basic example:
+- **Project ID**: 42
+- **Location**: hosted on GitLab.com
+- **Example API token**: `token`
+
+This command generates a changelog for version `1.0.0`.
+
+The commit range:
+
+- Starts with the tag of the last release.
+- Ends with the last commit on the target branch. The default target branch is the project's default branch.
+
+If the last tag is `v0.9.0` and the default branch is `main`, the range of commits
+included in this example is `v0.9.0..main`:
 
 ```shell
 curl --header "PRIVATE-TOKEN: token" --data "version=1.0.0" "https://gitlab.com/api/v4/projects/42/repository/changelog"
 ```
 
-This generates a changelog for version `1.0.0`. The start of the range of
-commits to include is the tag of the last release. The end of the range is the
-last commit on the target branch, which defaults to the project's default
-branch. So if the last tag is `v0.9.0`, and the default branch is `main`, this
-means the range of commits is `v0.9.0..main`.
-
-If you want to generate the data on a different branch, you can do so as
-follows:
+To generate the data on a different branch, specify the `branch` parameter. This
+command generates data from the `foo` branch:
 
 ```shell
 curl --header "PRIVATE-TOKEN: token" --data "version=1.0.0&branch=foo" "https://gitlab.com/api/v4/projects/42/repository/changelog"
 ```
 
-This generates the data on the `foo` branch.
-
-A different trailer to use is specified as follows:
+To use a different trailer, use the `trailer` parameter:
 
 ```shell
 curl --header "PRIVATE-TOKEN: token" --data "version=1.0.0&trailer=Type" "https://gitlab.com/api/v4/projects/42/repository/changelog"
 ```
 
-Or perhaps you want to store the results in a different file:
+To store the results in a different file, use the `file` parameter:
 
 ```shell
 curl --header "PRIVATE-TOKEN: token" --data "version=1.0.0&file=NEWS" "https://gitlab.com/api/v4/projects/42/repository/changelog"
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index eecc8ffd18f..358117ed796 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -74,15 +74,15 @@ runs by enabling the [Skip outdated deployment jobs](../pipelines/settings.md#sk
 
 Example of a problematic pipeline flow **before** enabling Skip outdated deployment jobs:
 
-1. Pipeline-A is created on the `master` branch.
-1. Later, Pipeline-B is created on the `master` branch (with a newer commit SHA).
+1. Pipeline-A is created on the default branch.
+1. Later, Pipeline-B is created on the default branch (with a newer commit SHA).
 1. The `deploy` job in Pipeline-B finishes first, and deploys the newer code.
 1. The `deploy` job in Pipeline-A finished later, and deploys the older code, **overwriting** the newer (latest) deployment.
 
 The improved pipeline flow **after** enabling Skip outdated deployment jobs:
 
-1. Pipeline-A is created on the `master` branch.
-1. Later, Pipeline-B is created on the `master` branch (with a newer SHA).
+1. Pipeline-A is created on the default branch.
+1. Later, Pipeline-B is created on the default branch (with a newer SHA).
 1. The `deploy` job in Pipeline-B finishes first, and deploys the newer code.
 1. The `deploy` job in Pipeline-A is automatically cancelled, so that it doesn't overwrite the deployment from the newer pipeline.
 
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index a5024e8a65f..40ba7cff5f9 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -180,7 +180,7 @@ $ vault write auth/jwt/config \
 
 For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api/auth/jwt#configure).
 
-The following job, when run for the `master` branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
+The following job, when run for the default branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
 
 ```yaml
 read_secrets:
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 2d7ba2bc759..62607320410 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -122,7 +122,7 @@ Therefore, for a production environment we use additional steps to ensure that a
 
 Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
 
-- Having a slightly different script for `master` branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
+- Having a slightly different script for the default branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
 - Instead of pushing it live, you can push it to WordPress official repository (with creating a SVN commit, etc.).
 - You could generate i18n text domains on the fly.
 
diff --git a/doc/ci/examples/semantic-release.md b/doc/ci/examples/semantic-release.md
index c0fc93fe1b3..6580719b969 100644
--- a/doc/ci/examples/semantic-release.md
+++ b/doc/ci/examples/semantic-release.md
@@ -126,7 +126,7 @@ Test the pipeline by creating a commit with a message like:
 fix: testing patch releases
 ```
 
-Push the commit to `master`. The pipeline should create a new release (`v1.0.0`) on the project's **Releases** page and publish a new version of the package to the project's **Package Registry** page.
+Push the commit to the default branch. The pipeline should create a new release (`v1.0.0`) on the project's **Releases** page and publish a new version of the package to the project's **Package Registry** page.
 
 To create a minor release, use a commit message like:
 
diff --git a/doc/ci/pipeline_editor/index.md b/doc/ci/pipeline_editor/index.md
index 9f4a1afe2f9..f85e287e3dc 100644
--- a/doc/ci/pipeline_editor/index.md
+++ b/doc/ci/pipeline_editor/index.md
@@ -8,10 +8,7 @@ type: reference
 # Pipeline Editor **(FREE)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4540) in GitLab 13.8.
-> - It's [deployed behind a feature flag](../../user/feature_flags.md), enabled by default.
-> - It's enabled on GitLab.com.
-> - It's recommended for production use.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-pipeline-editor). **(FREE SELF)**
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/270059) in GitLab 13.10.
 
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
@@ -30,7 +27,7 @@ From the pipeline editor page you can:
 
 NOTE:
 You must already have [a `.gitlab-ci.yml` file](../quick_start/index.md#create-a-gitlab-ciyml-file)
-on the default branch (usually `master`) of your project to use the editor.
+on the default branch of your project to use the editor.
 
 ## Validate CI configuration
 
@@ -68,7 +65,6 @@ reflected in the CI lint. It displays the same results as the existing [CI Lint
 
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
-It is not accessible if the [pipeline editor is disabled](#enable-or-disable-pipeline-editor).
 
 To view a visualization of your `gitlab-ci.yml` configuration, in your project,
 go to **CI/CD > Editor**, and then select the **Visualize** tab. The
@@ -150,22 +146,3 @@ If you enter a new branch name, the **Start a new merge request with these chang
 checkbox appears. Select it to start a new merge request after you commit the changes.
 
 ![The commit form with a new branch](img/pipeline_editor_commit_v13_8.png)
-
-## Enable or disable pipeline editor **(FREE SELF)**
-
-The pipeline editor is under development but ready for production use. It is
-deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
-can disable it.
-
-To disable it:
-
-```ruby
-Feature.disable(:ci_pipeline_editor_page)
-```
-
-To enable it:
-
-```ruby
-Feature.enable(:ci_pipeline_editor_page)
-```
diff --git a/doc/ci/quick_start/index.md b/doc/ci/quick_start/index.md
index 7ae76ad3a84..664523a08e4 100644
--- a/doc/ci/quick_start/index.md
+++ b/doc/ci/quick_start/index.md
@@ -66,7 +66,7 @@ In this file, you define:
 - The decisions the runner should make when specific conditions are encountered.
 
 For example, you might want to run a suite of tests when you commit to
-any branch except `master`. When you commit to `master`, you want
+any branch except the default branch. When you commit to the default branch, you want
 to run the same suite, but also publish your application.
 
 All of this is defined in the `.gitlab-ci.yml` file.
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index b44526135a1..fc83c45763a 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -31,8 +31,8 @@ In the above example:
 
 - A Review App is built every time a commit is pushed to `topic branch`.
 - The reviewer fails two reviews before passing the third review.
-- After the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
-- After having been approved in staging, the changes that were merged into `master` are deployed in to production.
+- After the review passes, `topic branch` is merged into the default branch, where it's deployed to staging.
+- After its approval in staging, the changes that were merged into the default branch are deployed to production.
 
 ## How Review Apps work
 
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 0f57a8e00e2..d4b9282ac38 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -164,7 +164,7 @@ a branch to its remote repository. To illustrate the problem, suppose you've had
 
 1. A user creates a feature branch named `example` and pushes it to a remote repository.
 1. A new pipeline starts running on the `example` branch.
-1. A user rebases the `example` branch on the latest `master` branch and force-pushes it to its remote repository.
+1. A user rebases the `example` branch on the latest default branch and force-pushes it to its remote repository.
 1. A new pipeline starts running on the `example` branch again, however,
    the previous pipeline (2) fails because of `fatal: reference is not a tree:` error.
 
diff --git a/doc/ci/unit_test_reports.md b/doc/ci/unit_test_reports.md
index c1720675d6a..e20d2a90192 100644
--- a/doc/ci/unit_test_reports.md
+++ b/doc/ci/unit_test_reports.md
@@ -28,7 +28,7 @@ in the pipeline detail view.
 
 Consider the following workflow:
 
-1. Your `master` branch is rock solid, your project is using GitLab CI/CD and
+1. Your default branch is rock solid, your project is using GitLab CI/CD and
    your pipelines indicate that there isn't anything broken.
 1. Someone from your team submits a merge request, a test fails and the pipeline
    gets the known red icon. To investigate more, you have to go through the job
@@ -44,7 +44,7 @@ First, GitLab Runner uploads all [JUnit report format XML files](https://www.ibm
 as [artifacts](pipelines/job_artifacts.md#artifactsreportsjunit) to GitLab. Then, when you visit a merge request, GitLab starts
 comparing the head and base branch's JUnit report format XML files, where:
 
-- The base branch is the target branch (usually `master`).
+- The base branch is the target branch (usually the default branch).
 - The head branch is the source branch (the latest pipeline in each merge request).
 
 The reports panel has a summary showing how many tests failed, how many had errors
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index c4aa60cccdd..51ddf5d3dd1 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -247,7 +247,7 @@ include:
 ```
 
 The [`MergeRequest-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/MergeRequest-Pipelines.gitlab-ci.yml)
-makes your pipelines run for the default branch (usually `master`), tags, and
+makes your pipelines run for the default branch, tags, and
 all types of merge request pipelines. Use this template if you use any of the
 the [Pipelines for Merge Requests features](../merge_request_pipelines/), as mentioned
 above.
@@ -1260,9 +1260,9 @@ Other commonly used variables for `if` clauses:
 
 - `if: $CI_COMMIT_TAG`: If changes are pushed for a tag.
 - `if: $CI_COMMIT_BRANCH`: If changes are pushed to any branch.
-- `if: '$CI_COMMIT_BRANCH == "master"'`: If changes are pushed to `master`.
+- `if: '$CI_COMMIT_BRANCH == "main"'`: If changes are pushed to `main`.
 - `if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'`: If changes are pushed to the default
-  branch (usually `master`). Use when you want to have the same configuration in multiple
+  branch. Use when you want to have the same configuration in multiple
   projects with different default branches.
 - `if: '$CI_COMMIT_BRANCH =~ /regex-expression/'`: If the commit branch matches a regular expression.
 - `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-cicd-variables)
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 29f2da8858f..c4418f37846 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -1607,34 +1607,31 @@ displayed for the page or feature.
 
 #### Version text in the **Version History**
 
-If all content in a section is related, add version text after the header
-for the section. The version information must be surrounded by blank lines, and
-each entry should be on its own line.
-
-Add the version history information as a blockquote:
+If all content in a section is related, add version text after the header for
+the section. The version information must:
+
+- Be surrounded by blank lines.
+- Start with `>`.
+- Version histories with more than one entry should have each entry on its own
+  line (long lines are okay). Start each line with `> -` to get unordered list
+  formatting.
+- Whenever possible, have a link to the completed issue, merge request, or epic
+  that introduced the feature. An issue is preferred over a merge request, and
+  a merge request is preferred over an epic.
 
 ```markdown
 ## Feature name
 
-> Introduced in GitLab 11.3.
+> [Introduced](<link-to-issue>) in GitLab 11.3.
 
 This feature does something.
-```
-
-Whenever possible, version text should have a link to the completed issue, merge
-request, or epic that introduced the feature. An issue is preferred over a merge
-request, and a merge request is preferred over an epic. For example:
-
-```markdown
-> [Introduced](<link-to-issue>) in GitLab 11.3.
-```
 
-If you're adding information about new features or changes in a release, update
-the blockquote to use a bulleted list:
+## Feature name 2
 
-```markdown
 > - [Introduced](<link-to-issue>) in GitLab 11.3.
-> - Enabled by default in GitLab 11.4.
+> - [Enabled by default](<link-to-issue>) in GitLab 11.4.
+
+This feature does something else.
 ```
 
 If a feature is moved to another tier:
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index 17516adf799..146114c99ad 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -41,8 +41,8 @@ On your profile page, you can see the following information:
 - Personal projects: your personal projects (respecting the project's visibility level)
 - Starred projects: projects you starred
 - Snippets: your personal code [snippets](../snippets.md#personal-snippets)
-- Followers: people following you
-- Following: people you are following
+- Followers: people [following](../index.md#user-activity) you
+- Following: people you are [following](../index.md#user-activity)
 
 Profile page with active Following view: