Add latest changes from gitlab-org/gitlab@master

22 files changed, 58 insertions, 28 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index d0ea9994ef7..92e6add9f17 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -571,7 +571,8 @@ module Types
 end
 ```
 
-NOTE: **Note:** If the field's type already [has a particular
+NOTE: **Note:**
+If the field's type already [has a particular
 authorization](#type-authorization) then there is no need to add that
 same authorization to the field.
 
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index b5b0a4f13e8..4d296451add 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -27,7 +27,8 @@ limit values. It's recommended to create separate migration script files.
   add_column(:plan_limits, :project_hooks, :integer, default: 100, null: false)
   ```
 
-  NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
+  NOTE: **Note:**
+  Plan limits entries set to `0` mean that limits are not
   enabled. You should use this setting only in special and documented circumstances.
 
 1. (Optionally) Create the database migration that fine-tunes each level with
@@ -57,7 +58,8 @@ limit values. It's recommended to create separate migration script files.
   end
   ```
 
-NOTE: **Note:** Some plans exist only on GitLab.com. This will be no-op
+NOTE: **Note:**
+Some plans exist only on GitLab.com. This will be no-op
 for plans that do not exist.
 
 ### Plan limits validation
@@ -95,7 +97,8 @@ can be used to validate that a model does not exceed the limits. It ensures
 that the count of the records for the current model does not exceed the defined
 limit.
 
-NOTE: **Note:** You must specify the limit scope of the object being validated
+NOTE: **Note:**
+You must specify the limit scope of the object being validated
 and the limit name if it's different from the pluralized model name.
 
 ```ruby
@@ -143,4 +146,5 @@ GitLab.com:
 - `silver` - Namespaces and projects with a Silver subscription
 - `gold` - Namespaces and projects with a Gold subscription
 
-NOTE: **Note:** The test environment doesn't have any plans.
+NOTE: **Note:**
+The test environment doesn't have any plans.
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 33c5e7ed3ce..a3a4f1d7adc 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -17,7 +17,8 @@ To request access to Chatops on GitLab.com:
     1. You could also use the "Sign in with" Google button to sign in, with your GitLab.com email address.
 1. Ask in the [#production](https://gitlab.slack.com/messages/production) channel for an existing member to add you to the `chatops` project in Ops. They can do it by running `/chatops run member add <username> gitlab-com/chatops --ops` command in that channel.
 
-NOTE: **Note:** If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
+NOTE: **Note:**
+If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
 
 ## See also
 
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md
index 4be671644ff..e0cca00fd69 100644
--- a/doc/development/cicd/index.md
+++ b/doc/development/cicd/index.md
@@ -92,7 +92,8 @@ A job with the `created` state won't be seen by the Runner yet. To make it possi
 
 When the Runner is connected, it requests the next `pending` job to run by polling the server continuously.
 
-NOTE: **Note:** API endpoints used by the Runner to interact with GitLab are defined in [`lib/api/runner.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/runner.rb)
+NOTE: **Note:**
+API endpoints used by the Runner to interact with GitLab are defined in [`lib/api/runner.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/runner.rb)
 
 After the server receives the request it selects a `pending` job based on the [`Ci::RegisterJobService` algorithm](#ciregisterjobservice), then assigns and sends the job to the Runner.
 
@@ -126,7 +127,8 @@ There are 3 top level queries that this service uses to gather the majority of t
 
 This list of jobs is then filtered further by matching tags between job and Runner tags.
 
-NOTE: **Note:** If a job contains tags, the Runner will not pick the job if it does not match **all** the tags.
+NOTE: **Note:**
+If a job contains tags, the Runner will not pick the job if it does not match **all** the tags.
 The Runner may have more tags than defined for the job, but not vice-versa.
 
 Finally if the Runner can only pick jobs that are tagged, all untagged jobs are filtered out.
diff --git a/doc/development/database/add_foreign_key_to_existing_column.md b/doc/development/database/add_foreign_key_to_existing_column.md
index b8817eddeec..1b41a52c95e 100644
--- a/doc/development/database/add_foreign_key_to_existing_column.md
+++ b/doc/development/database/add_foreign_key_to_existing_column.md
@@ -113,7 +113,8 @@ end
 
 Validating the foreign key will scan the whole table and make sure that each relation is correct.
 
-NOTE: **Note:** When using [background migrations](../background_migrations.md), foreign key validation should happen in the next GitLab release.
+NOTE: **Note:**
+When using [background migrations](../background_migrations.md), foreign key validation should happen in the next GitLab release.
 
 Migration file for validating the foreign key:
 
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 5405a8808f0..f864f13f489 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -190,7 +190,8 @@ In general, migrations for a single deploy shouldn't take longer than
 1 hour for GitLab.com. The following guidelines are not hard rules, they were
 estimated to keep migration timing to a minimum.
 
-NOTE: **Note:** Keep in mind that all runtimes should be measured against GitLab.com.
+NOTE: **Note:**
+Keep in mind that all runtimes should be measured against GitLab.com.
 
 | Migration Type | Execution Time Recommended | Notes |
 |----|----|---|
diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md
index 71020e6054e..ba265e26b52 100644
--- a/doc/development/documentation/site_architecture/global_nav.md
+++ b/doc/development/documentation/site_architecture/global_nav.md
@@ -98,7 +98,7 @@ for clarity.
 To see the improvements planned, check the
 [global nav epic](https://gitlab.com/groups/gitlab-com/-/epics/21).
 
-CAUTION: **Attention!**
+NOTE: **Note:**
 **Do not** [add items](#adding-new-items) to the global nav without
 the consent of one of the technical writers.
 
@@ -275,7 +275,7 @@ and the following syntax rules.
   an "information" icon on the nav to make the user aware that the feature is
   EE-only.
 
-DANGER: **Important!**
+CAUTION: **Caution:**
 All links present on the data file must end in `.html`, not `.md`. Do not
 start any relative link with a forward slash `/`.
 
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 027c383bc6c..60e6d4bcb13 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -111,7 +111,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):
 
-CAUTION: **Caution**
+CAUTION: **Caution:**
 If you change the dockerfile configuration and rebuild the images, you can break the master
 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.
diff --git a/doc/development/geo/framework.md b/doc/development/geo/framework.md
index e8e38372664..de4d6fb869d 100644
--- a/doc/development/geo/framework.md
+++ b/doc/development/geo/framework.md
@@ -1,11 +1,13 @@
 # Geo self-service framework (alpha)
 
-NOTE: **Note:** This document might be subjected to change. It's a
+NOTE: **Note:**
+This document might be subjected to change. It's a
 proposal we're working on and once the implementation is complete this
 documentation will be updated. Follow progress in the
 [epic](https://gitlab.com/groups/gitlab-org/-/epics/2161).
 
-NOTE: **Note:** The Geo self-service framework is currently in
+NOTE: **Note:**
+The Geo self-service framework is currently in
 alpha. If you need to replicate a new data type, reach out to the Geo
 team to discuss the options. You can contact them in `#g_geo` on Slack
 or mention `@geo-team` in the issue or merge request.
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index 417c96a44dd..60f0823536e 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -114,7 +114,8 @@ bundle exec rake gitlab:features:disable_rugged
 
 Most of this code exists in the `lib/gitlab/git/rugged_impl` directory.
 
-NOTE: **Note:** You should NOT need to add or modify code related to
+NOTE: **Note:**
+You should NOT need to add or modify code related to
 Rugged unless explicitly discussed with the [Gitaly
 Team](https://gitlab.com/groups/gl-gitaly/group_members). This code will
 NOT work on GitLab.com or other GitLab instances that do not use NFS.
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index bdd372e90ed..bce95dfc24e 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -95,7 +95,8 @@ Active Record's `:message` option accepts a `Proc`, so we can do this instead:
 validates :group_id, uniqueness: { scope: [:project_id], message: -> (object, data) { _("already shared with this group") } }
 ```
 
-NOTE: **Note:** Messages in the API (`lib/api/` or `app/graphql`) do
+NOTE: **Note:**
+Messages in the API (`lib/api/` or `app/graphql`) do
 not need to be externalised.
 
 ### HAML files
diff --git a/doc/development/import_export.md b/doc/development/import_export.md
index ecdfd8a853e..556fa6c7db4 100644
--- a/doc/development/import_export.md
+++ b/doc/development/import_export.md
@@ -408,4 +408,5 @@ tree
     └── 4352.json
 ```
 
-CAUTION: **Caution:** When updating these fixtures, please ensure you update both `json` files and `tree` folder, as the tests apply to both.
+CAUTION: **Caution:**
+When updating these fixtures, please ensure you update both `json` files and `tree` folder, as the tests apply to both.
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index 1c5beffea1a..1fa6ea5d405 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -17,7 +17,8 @@ The first option is to simply [import the Project tarball file via the GitLab UI
 
 It should take up to 15 minutes for the project to fully import. You can head to the project's main page for the current status.
 
-NOTE: **Note:** This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab's users. For development and testing, check the other methods below.
+NOTE: **Note:**
+This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab's users. For development and testing, check the other methods below.
 
 ### Importing via the `import-project` script
 
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 833693e896d..22de9bc9c58 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -604,7 +604,8 @@ In this particular case, the default value exists and we're just changing the me
 `request_access_enabled` column, which does not imply a rewrite of all the existing records
 in the `namespaces` table. Only when creating a new column with a default, all the records are going be rewritten.
 
-NOTE: **Note:**  A faster [ALTER TABLE ADD COLUMN with a non-null default](https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/)
+NOTE: **Note:**
+A faster [ALTER TABLE ADD COLUMN with a non-null default](https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-fast-alter-table-add-column-with-a-non-null-default/)
 was introduced on PostgresSQL 11.0, removing the need of rewriting the table when a new column with a default value is added.
 
 For the reasons mentioned above, it's safe to use `change_column_default` in a single-transaction migration
diff --git a/doc/development/packages.md b/doc/development/packages.md
index edf01255e84..ae67af10d88 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -68,7 +68,8 @@ The current state of existing package registries availability is:
 | Go              | Yes | No - [open issue](https://gitlab.com/gitlab-org/gitlab/-/issues/213900) | No - [open-issue](https://gitlab.com/gitlab-org/gitlab/-/issues/213902) |
 | Composer | Yes | Yes | No |
 
-NOTE: **Note:** NPM is currently a hybrid of the instance level and group level.
+NOTE: **Note:**
+NPM is currently a hybrid of the instance level and group level.
 It is using the top-level group or namespace as the defining portion of the name
 (for example, `@my-group-name/my-package-name`).
 
diff --git a/doc/development/performance.md b/doc/development/performance.md
index b33fc8b246f..16ea1aa27ff 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -272,7 +272,8 @@ Currently supported profiling targets are:
 - Puma worker
 - Sidekiq
 
-NOTE: **Note:** The Puma master process is not supported. Neither is Unicorn.
+NOTE: **Note:**
+The Puma master process is not supported. Neither is Unicorn.
 Sending SIGUSR2 to either of those will trigger restarts. In the case of Puma,
 take care to only send the signal to Puma workers.
 
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index 2cab6750b9b..f7ead94d725 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -10,7 +10,8 @@ There is a `Gitlab::Profiler.profile` method, and corresponding
 `bin/profile-url` script, that enable profiling a GET or POST request to a
 specific URL, either as an anonymous user (the default) or as a specific user.
 
-NOTE: **Note:** The first argument to the profiler is either a full URL
+NOTE: **Note:**
+The first argument to the profiler is either a full URL
 (including the instance hostname) or an absolute path, including the
 leading slash.
 
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index 04c310288d2..2793756ff64 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -303,7 +303,8 @@ class ExternalDependencyWorker
 end
 ```
 
-NOTE: **Note:** Note that a job cannot be both high urgency and have
+NOTE: **Note:**
+Note that a job cannot be both high urgency and have
 external dependencies.
 
 ## CPU-bound and Memory-bound Workers
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 2b0dd473129..4e46e691405 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -110,7 +110,8 @@ Use the coverage reports to ensure your tests cover 100% of your code.
 
 ### System / Feature tests
 
-NOTE: **Note:** Before writing a new system test, [please consider **not**
+NOTE: **Note:**
+Before writing a new system test, [please consider **not**
 writing one](testing_levels.md#consider-not-writing-a-system-test)!
 
 - Feature specs should be named `ROLE_ACTION_spec.rb`, such as
diff --git a/doc/development/testing_guide/end_to_end/environment_selection.md b/doc/development/testing_guide/end_to_end/environment_selection.md
index 698d061ced2..9eb7db72a51 100644
--- a/doc/development/testing_guide/end_to_end/environment_selection.md
+++ b/doc/development/testing_guide/end_to_end/environment_selection.md
@@ -33,7 +33,7 @@ RSpec.describe 'Area' do
   it 'runs in any environment' do; end
 
   it 'runs only in production', only: :production do; end
-  
+
   it 'runs only in staging', only: { subdomain: :staging } do; end
 
   it 'runs in dev', only: { tld: '.org', domain: 'gitlab', subdomain: 'dev' } do; end
@@ -45,3 +45,10 @@ end
 NOTE: **Note:**
 If the test has a `before` or `after`, you must add the `only` metadata
 to the outer `RSpec.describe`.
+
+## Quarantining a test for a specific environment
+
+Similarly to specifying that a test should only run against a specific environment, it's also possible to quarantine a
+test only when it runs against a specific environment. The syntax is exactly the same, except that the `only: { ... }`
+hash is nested in the [`quarantine: { ... }`](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests) hash.
+For instance, `quarantine: { only: { subdomain: :staging } }` will only quarantine the test when run against staging.
diff --git a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
index 61d14b586ea..4059c1960e2 100644
--- a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
+++ b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
@@ -10,7 +10,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:elasticsearch`  | The test requires an Elasticsearch service. It is used by the [instance-level scenario](https://gitlab.com/gitlab-org/gitlab-qa#definitions) [`Test::Integration::Elasticsearch`](https://gitlab.com/gitlab-org/gitlab/-/blob/72b62b51bdf513e2936301cb6c7c91ec27c35b4d/qa/qa/ee/scenario/test/integration/elasticsearch.rb) to include only tests that require Elasticsearch. |
 | `:kubernetes`     | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test will also include provisioning of at least one Kubernetes cluster to test against. *This tag is often be paired with `:orchestrated`.* |
 | `:orchestrated`   | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
-| `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), will run in a separate job that only includes quarantined tests, and is allowed to fail. The test will be skipped in its regular job so that if it fails it will not hold up the pipeline. |
+| `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), will run in a separate job that only includes quarantined tests, and is allowed to fail. The test will be skipped in its regular job so that if it fails it will not hold up the pipeline. Note that you can also [quarantine a test only when it runs against specific environment](environment_selection.md#quarantining-a-test-for-a-specific-environment). |
 | `:reliable`       | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/guidelines/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
 | `:requires_admin` | The test requires an admin account. Tests with the tag are excluded when run against Canary and Production environments. |
 | `:runner`         | The test depends on and will set up a GitLab Runner instance, typically to run a pipeline. |
diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md
index d9907abbb92..d0b8aa18f5c 100644
--- a/doc/development/what_requires_downtime.md
+++ b/doc/development/what_requires_downtime.md
@@ -130,7 +130,8 @@ class CleanupUsersUpdatedAtRename < ActiveRecord::Migration[4.2]
 end
 ```
 
-NOTE: **Note:** If you're renaming a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3), please carefully consider the state when the first migration has run but the second cleanup migration hasn't been run yet.
+NOTE: **Note:**
+If you're renaming a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3), please carefully consider the state when the first migration has run but the second cleanup migration hasn't been run yet.
 With [Canary](https://about.gitlab.com/handbook/engineering/infrastructure/library/canary/) it is possible that the system runs in this state for a significant amount of time.
 
 ## Changing Column Constraints