Merge branch 'docs-unassign-main-master' into 'master'

Update unassigned files to use main for master

See merge request gitlab-org/gitlab!64137

doc/development/architecture.md

@@ -15,14 +15,14 @@ There are two software distributions of GitLab:
 
 GitLab is available under [different subscriptions](https://about.gitlab.com/pricing/).
 
-New versions of GitLab are released from stable branches, and the `master` branch is used for
+New versions of GitLab are released from stable branches, and the `main` branch is used for
 bleeding-edge development.
 
 For more information, visit the [GitLab Release Process](https://about.gitlab.com/handbook/engineering/releases/).
 
 Both distributions require additional components. These components are described in the
 [Component details](#components) section, and all have their own repositories.
-New versions of each dependent component are usually tags, but staying on the `master` branch of the
+New versions of each dependent component are usually tags, but staying on the `main` branch of the
 GitLab codebase gives you the latest stable version of those components. New versions are
 generally released around the same time as GitLab releases, with the exception of informal security
 updates deemed critical.

doc/development/code_review.md

@@ -418,13 +418,13 @@ WARNING:
 - Start a new merge request pipeline with the `Run pipeline` button in the merge
   request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).
   Note that:
-  - If **[master is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
+  - If **[main is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
     do not merge the merge request** except for
     [very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master).
     For other cases, follow these [handbook instructions](https://about.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master).
   - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results)** finished less than 2 hours ago, you
     might merge without starting a new pipeline as the merge request is close
-    enough to `master`.
+    enough to `main`.
 - When you set the MR to "Merge When Pipeline Succeeds", you should take over
   subsequent revisions for anything that would be spotted after that.
 - For merge requests that have had [Squash and
@@ -434,11 +434,11 @@ WARNING:
 
 Thanks to **Pipeline for Merged Results**, authors no longer have to rebase their
 branch as frequently anymore (only when there are conflicts) because the Merge
-Results Pipeline already incorporate the latest changes from `master`.
+Results Pipeline already incorporate the latest changes from `main`.
 This results in faster review/merge cycles because maintainers don't have to ask
 for a final rebase: instead, they only have to start a MR pipeline and set MWPS.
 This step brings us very close to the actual Merge Trains feature by testing the
-Merge Results against the latest `master` at the time of the pipeline creation.
+Merge Results against the latest `main` at the time of the pipeline creation.
 
 ### Community contributions
 

doc/development/contributing/issue_workflow.md

@@ -325,7 +325,7 @@ the [appropriate product manager](https://about.gitlab.com/handbook/product/#who
 as soon as possible. The product manager will then pull in appropriate GitLab team
 members to further discuss scope, design, and technical considerations. This will
 ensure that your contribution is aligned with the GitLab product and minimize
-any rework and delay in getting it merged into master.
+any rework and delay in getting it merged into main.
 
 GitLab team members who apply the ~"Accepting merge requests" label to an issue
 should update the issue description with a responsible product manager, inviting

doc/development/contributing/merge_request_workflow.md

@@ -44,7 +44,7 @@ request is as follows:
 
 1. [Fork](../../user/project/repository/forking_workflow.md) the project into
    your personal namespace (or group) on GitLab.com.
-1. Create a feature branch in your fork (don't work off `master`).
+1. Create a feature branch in your fork (don't work off your [default branch](../../user/project/repository/branches/default.md)).
 1. Write [tests](../rake_tasks.md#run-tests) and code.
 1. [Ensure a changelog is created](../changelog.md).
 1. If you are writing documentation, make sure to follow the
@@ -54,7 +54,7 @@ request is as follows:
    commits by [squashing them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing),
    but do not change the commit history if you're working on shared branches though.
 1. Push the commit(s) to your working branch in your fork.
-1. Submit a merge request (MR) to the `master` branch in the main GitLab project.
+1. Submit a merge request (MR) to the `main` branch in the main GitLab project.
    1. Your merge request needs at least 1 approval, but depending on your changes
       you might need additional approvals. Refer to the [Approval guidelines](../code_review.md#approval-guidelines).
    1. You don't have to select any specific approvers, but you can if you really want
@@ -196,12 +196,12 @@ the contribution acceptance criteria below:
    exposing a bug in existing code). Every new class should have corresponding
    unit tests, even if the class is exercised at a higher level, such as a feature test.
    - If a failing CI build seems to be unrelated to your contribution, you can try
-     restarting the failing CI job, rebasing from `master` to bring in updates that
+     restarting the failing CI job, rebasing from `main` to bring in updates that
      may resolve the failure, or if it has not been fixed yet, ask a developer to
      help you fix the test.
 1. The MR initially contains a few logically organized commits.
 1. The changes can merge without problems. If not, you should rebase if you're the
-   only one working on your feature branch, otherwise merge `master`.
+   only one working on your feature branch, otherwise merge `main`.
 1. Only one specific issue is fixed or one specific feature is implemented. Do not
    combine things; send separate merge requests for each issue or feature.
 1. Migrations should do only one thing (e.g., create a table, move data to a new

doc/development/diffs.md

@@ -156,13 +156,13 @@ Historically, merge request diffs have been calculated by `git diff target...sou
 `HEAD` of the source branch with the merge base (or a common ancestor) of the target branch and the source's.
 This solution works well until the target branch starts containing some of the
 changes introduced by the source branch: Consider the following case, in which the source branch
-is `feature_a` and the target is `master`:
+is `feature_a` and the target is `main`:
 
-1. Checkout a new branch `feature_a` from `master` and remove `file_a` and `file_b` in it.
-1. Add a commit that removes `file_a` to `master`.
+1. Checkout a new branch `feature_a` from `main` and remove `file_a` and `file_b` in it.
+1. Add a commit that removes `file_a` to `main`.
 
 The merge request diff still contains the `file_a` removal while the actual diff compared to
-`master`'s `HEAD` has only the `file_b` removal. The diff with such redundant
+`main`'s `HEAD` has only the `file_b` removal. The diff with such redundant
 changes is harder to review.
 
 In order to display an up-to-date diff, in GitLab 12.9 we
@@ -174,16 +174,16 @@ diff.
 
 Until we complete the epics ["use merge refs for diffs"](https://gitlab.com/groups/gitlab-org/-/epics/854)
 and ["merge conflicts in diffs"](https://gitlab.com/groups/gitlab-org/-/epics/4893),
-both options `master (base)` and `master (HEAD)` are available to be displayed in merge requests:
+both options `main (base)` and `main (HEAD)` are available to be displayed in merge requests:
 
 ![Merge ref head options](img/merge_ref_head_options_v13_6.png)
 
-The `master (HEAD)` option is meant to replace `master (base)` in the future.
+The `main (HEAD)` option is meant to replace `main (base)` in the future.
 
 In order to support comments for both options, diff note positions are stored for
-both `master (base)` and `master (HEAD)` versions ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198457) in 12.10).
-The position for `master (base)` version is stored in `Note#position` and
-`Note#original_position` columns, for `master (HEAD)` version `DiffNotePosition`
+both `main (base)` and `main (HEAD)` versions ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198457) in 12.10).
+The position for `main (base)` version is stored in `Note#position` and
+`Note#original_position` columns, for `main (HEAD)` version `DiffNotePosition`
 has been introduced.
 
 One of the key challenges to deal with when working on merge ref diffs are merge

doc/development/documentation/index.md

@@ -317,7 +317,8 @@ it increases the work of the release managers.
 Every GitLab instance includes the documentation, which is available at `/help`
 (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
 
-The documentation available online on <https://docs.gitlab.com> is deployed every four hours from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
+The documentation available online on <https://docs.gitlab.com> is deployed every
+four hours from the `main` branch of GitLab, Omnibus, and Runner. Therefore,
 after a merge request gets merged, it is available online on the same day.
 However, it's shipped (and available on `/help`) within the milestone assigned
 to the MR.
@@ -461,7 +462,7 @@ If you want to know the in-depth details, here's what's really happening:
 1. You manually run the `review-docs-deploy` job in a merge request.
 1. The job runs the [`scripts/trigger-build`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/trigger-build)
    script with the `docs deploy` flag, which triggers the "Triggered from `gitlab-org/gitlab` 'review-docs-deploy' job"
-   pipeline trigger in the `gitlab-org/gitlab-docs` project for the `$DOCS_BRANCH` (defaults to `master`).
+   pipeline trigger in the `gitlab-org/gitlab-docs` project for the `$DOCS_BRANCH` (defaults to `main`).
 1. The preview URL is shown both at the job output and in the merge request
    widget. You also get the link to the remote pipeline.
 1. In the `gitlab-org/gitlab-docs` project, the pipeline is created and it

doc/development/documentation/site_architecture/deployment_process.md

@@ -55,10 +55,10 @@ The website keeps changing and being improved. In order to consolidate
 those changes to the stable branches, we'd need to pick certain changes
 from time to time.
 
-If this is not possible or there are many changes, merge master into them:
+If this is not possible or there are many changes, merge main into them:
 
 ```shell
 git branch 12.0
-git fetch origin master
-git merge origin/master
+git fetch origin main
+git merge origin/main
 ```

doc/development/documentation/site_architecture/index.md

@@ -114,7 +114,7 @@ located in the [Dockerfiles directory](https://gitlab.com/gitlab-org/gitlab-docs
 If you need to rebuild the Docker images immediately (must have maintainer level permissions):
 
 WARNING:
-If you change the Dockerfile configuration and rebuild the images, you can break the master
+If you change the Dockerfile configuration and rebuild the images, you can break the main
 pipeline in the main `gitlab` repository as well as in `gitlab-docs`. Create an image with
 a different name first and test it to ensure you do not break the pipelines.
 
@@ -132,7 +132,7 @@ a different name first and test it to ensure you do not break the pipelines.
 ### Deploy the docs site
 
 Every four hours a scheduled pipeline builds and deploys the docs site. The pipeline
-fetches the current docs from the main project's master branch, builds it with Nanoc
+fetches the current docs from the main project's main branch, builds it with Nanoc
 and deploys it to <https://docs.gitlab.com>.
 
 If you need to build and deploy the site immediately (must have maintainer level permissions):

doc/development/documentation/styleguide/index.md

@@ -1276,7 +1276,7 @@ hidden on the documentation site, but is displayed by `/help`.
 ## Code blocks
 
 - Always wrap code added to a sentence in inline code blocks (`` ` ``).
-  For example, `.gitlab-ci.yml`, `git add .`, `CODEOWNERS`, or `only: [master]`.
+  For example, `.gitlab-ci.yml`, `git add .`, `CODEOWNERS`, or `only: [main]`.
   File names, commands, entries, and anything that refers to code should be
   added to code blocks. To make things easier for the user, always add a full
   code block for things that can be useful to copy and paste, as they can do it

doc/development/feature_flags/index.md

@@ -41,7 +41,7 @@ should be leveraged:
 
   1. [Create a new feature flag](#create-a-new-feature-flag)
      which is **off** by default, in the first merge request which uses the flag.
-     Flags [should not be added separately](#risk-of-a-broken-master-main-branch).
+     Flags [should not be added separately](#risk-of-a-broken-main-branch).
   1. Submit incremental changes via one or more merge requests, ensuring that any
      new code added can only be reached if the feature flag is **on**.
      You can keep the feature flag enabled on your local GDK during development.
@@ -59,11 +59,11 @@ flag does not have to stick around for a specific amount of time
 is deemed stable. Stable means it works on GitLab.com without causing any
 problems, such as outages.
 
-## Risk of a broken master (main) branch
+## Risk of a broken main branch
 
-Feature flags **must** be used in the MR that introduces them. Not doing so causes a
-[broken master](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
-to the `rspec:feature-flags` job that only runs on the `master` branch.
+Feature flags must be used in the MR that introduces them. Not doing so causes a
+[broken main branch](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
+to the `rspec:feature-flags` job that only runs on the `main` branch.
 
 ## Types of feature flags
 

doc/development/migration_style_guide.md

@@ -45,16 +45,16 @@ columns manually for existing tables as this causes confusion to
 other people using `db/structure.sql` generated by Rails.
 
 When your local database in your GDK is diverging from the schema from
-`master` it might be hard to cleanly commit the schema changes to
+`main` it might be hard to cleanly commit the schema changes to
 Git. In that case you can use the `scripts/regenerate-schema` script to
 regenerate a clean `db/structure.sql` for the migrations you're
 adding. This script applies all migrations found in `db/migrate`
 or `db/post_migrate`, so if there are any migrations you don't want to
 commit to the schema, rename or remove them. If your branch is not
-targeting `master` you can set the `TARGET` environment variable.
+targeting `main` you can set the `TARGET` environment variable.
 
 ```shell
-# Regenerate schema against `master`
+# Regenerate schema against `main`
 scripts/regenerate-schema
 
 # Regenerate schema against `12-9-stable-ee`

doc/development/new_fe_guide/development/performance.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
-Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes are pushed live on the next scheduled run after the changes are merged into `master`.
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes are pushed live on the next scheduled run after the changes are merged into `main`.
 
 There are 3 recommended high impact metrics to review on each page:
 

doc/development/pipelines.md

@@ -24,7 +24,7 @@ feature of the GitLab CI/CD.
 
 Pipelines are always created for the following scenarios:
 
-- `master` branch, including on schedules, pushes, merges, and so on.
+- `main` branch, including on schedules, pushes, merges, and so on.
 - Merge requests.
 - Tags.
 - Stable, `auto-deploy`, and security branches.
@@ -428,7 +428,7 @@ We are using a custom mapping between source file to test files, maintained in t
 
 As part of the objective to improve overall pipeline duration, we are experimenting with a minimal set of RSpec tests.
 The purpose of this experiment is to verify if we are able to run a minimal set of RSpec tests in a Merge Request pipeline,
-without resulting in increased number of broken master.
+without resulting in increased number of broken main branch.
 
 To identify the minimal set of tests needed, we use [Crystalball gem](https://github.com/toptal/crystalball) to create a test mapping.
 The test mapping contains a map of each source files to a list of test files which is dependent of the source file.
@@ -484,14 +484,14 @@ Our test suite runs against PG12 as GitLab.com runs on PG12 and
 Our test suite is currently running against PG11, since GitLab.com still runs on PG11.
 
 We do run our test suite against PG11 on nightly scheduled pipelines as well as upon specific
-database library changes in MRs and `master` pipelines (with the `rspec db-library-code pg11` job).
+database library changes in MRs and `main` pipelines (with the `rspec db-library-code pg11` job).
 
 #### Current versions testing
 
 | Where? | PostgreSQL version |
 | ------ | ------------------ |
 | MRs    | 12, 11 for DB library changes |
-| `master` (non-scheduled pipelines) | 12, 11 for DB library changes |
+| `main` (non-scheduled pipelines) | 12, 11 for DB library changes |
 | 2-hourly scheduled pipelines | 12, 11 for DB library changes |
 | `nightly` scheduled pipelines | 12, 11 |
 
@@ -538,7 +538,7 @@ the `gitlab-org/gitlab-foss` project.
 ### Interruptible pipelines
 
 By default, all jobs are [interruptible](../ci/yaml/README.md#interruptible), except the
-`dont-interrupt-me` job which runs automatically on `master`, and is `manual`
+`dont-interrupt-me` job which runs automatically on `main`, and is `manual`
 otherwise.
 
 If you want a running pipeline to finish even if you push new commits to a merge

doc/development/rake_tasks.md

@@ -236,7 +236,7 @@ task, then check the dimensions of the new sprite sheet and update the
 ## Update project templates
 
 Starting a project from a template needs this project to be exported. On a
-up to date master branch run:
+up to date main branch run:
 
 ```shell
 gdk start
@@ -247,7 +247,7 @@ git commit
 git push -u origin update-project-templates
 ```
 
-Now create a merge request and merge that to master.
+Now create a merge request and merge that to main.
 
 ## Generate route lists
 

doc/development/testing_guide/best_practices.md

@@ -1148,7 +1148,7 @@ module Spec
     module Helpers
       module CycleAnalyticsHelpers
         def create_commit_referencing_issue(issue, branch_name: random_git_name)
-          project.repository.add_branch(user, branch_name, 'master')
+          project.repository.add_branch(user, branch_name, 'main')
           create_commit("Commit for ##{issue.iid}", issue.project, user, branch_name)
         end
       end
@@ -1205,7 +1205,7 @@ let(:project) { create(:project, :repository) }
 ```
 
 Where you can, consider using the `:custom_repo` trait instead of `:repository`.
-This allows you to specify exactly what files appear in the `master` branch
+This allows you to specify exactly what files appear in the `main` branch
 of the project's repository. For example:
 
 ```ruby

doc/development/testing_guide/ci.md

@@ -12,7 +12,7 @@ Our current CI parallelization setup is as follows:
 
 1. The `retrieve-tests-metadata` job in the `prepare` stage ensures we have a
    `knapsack/report-master.json` file:
-   - The `knapsack/report-master.json` file is fetched from the latest `master` pipeline which runs `update-tests-metadata`
+   - The `knapsack/report-master.json` file is fetched from the latest `main` pipeline which runs `update-tests-metadata`
      (for now it's the 2-hourly scheduled master pipeline), if it's not here we initialize the file with `{}`.
 1. Each `[rspec|rspec-ee] [unit|integration|system|geo] n m` job are run with
    `knapsack rspec` and should have an evenly distributed share of tests:
@@ -31,7 +31,7 @@ After that, the next pipeline uses the up-to-date `knapsack/report-master.json`
 
 ## Monitoring
 
-The GitLab test suite is [monitored](../performance.md#rspec-profiling) for the `master` branch, and any branch
+The GitLab test suite is [monitored](../performance.md#rspec-profiling) for the `main` branch, and any branch
 that includes `rspec-profile` in their name.
 
 ## CI setup

doc/development/testing_guide/end_to_end/feature_flags.md

@@ -81,7 +81,7 @@ End-to-end tests should pass with a feature flag enabled before it is enabled on
 
 If a test enables a feature flag as describe above, it is sufficient to run the `package-and-qa` job in a merge request containing the relevant changes.
 Or, if the feature flag and relevant changes have already been merged, you can confirm that the tests
-pass on `master`. The end-to-end tests run on `master` every two hours, and the results are posted to a [Test
+pass on `main`. The end-to-end tests run on `main` every two hours, and the results are posted to a [Test
 Session Report, which is available in the testcase-sessions project](https://gitlab.com/gitlab-org/quality/testcase-sessions/-/issues?label_name%5B%5D=found%3Amaster).
 
 If the relevant tests do not enable the feature flag themselves, you can check if the tests will need

doc/development/testing_guide/flaky_tests.md

@@ -13,7 +13,7 @@ eventually.
 
 ## Quarantined tests
 
-When a test frequently fails in `master`,
+When a test frequently fails in `main`,
 [a ~"master:broken" issue](https://about.gitlab.com/handbook/engineering/workflow/#broken-master)
 should be created.
 If the test cannot be fixed in a timely fashion, there is an impact on the
@@ -56,7 +56,7 @@ On our CI, we use [RSpec::Retry](https://github.com/NoRedInk/rspec-retry) to aut
 times (see [`spec/spec_helper.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/spec_helper.rb) for the precise retries count).
 
 We also use a home-made `RspecFlaky::Listener` listener which records flaky
-examples in a JSON report file on `master` (`retrieve-tests-metadata` and
+examples in a JSON report file on `main` (`retrieve-tests-metadata` and
 `update-tests-metadata` jobs).
 
 This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13021>.

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -137,8 +137,8 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    # Change into the upstream repo directory:
    cd test-git-lfs-repo-migration
 
-   # You may need to reset your local copy with upstream's `master` after force-pushing from the mirror:
-   git reset --hard origin/master
+   # You may need to reset your local copy with upstream's `main` after force-pushing from the mirror:
+   git reset --hard origin/main
 
    # Track the files with LFS:
    git lfs track "*.gif" "*.png" "*.jpg" "*.psd" "*.mp4" "img/"

doc/user/project/merge_requests/versions.md

@@ -64,7 +64,7 @@ In GitLab 12.10, we added a comparison mode, which
 shows a diff calculated by simulating how it would look like once merged - a more accurate
 representation of the changes rather than using the base of the two
 branches. The new mode is available from the comparison target drop down
-by selecting **master (HEAD)**. In GitLab 13.9, it
+by selecting **main (HEAD)**. In GitLab 13.9, it
 [replaced](https://gitlab.com/gitlab-org/gitlab/-/issues/198458) the
 old default comparison. For technical details, additional information is available in the
 [developer documentation](../../../development/diffs.md#merge-request-diffs-against-the-head-of-the-target-branch).