Add latest changes from gitlab-org/gitlab@14-6-stable-eev14.6.0-rc42

8 files changed, 27 insertions, 27 deletions

diff --git a/.gitlab/merge_request_templates/Change Documentation Location.md b/.gitlab/merge_request_templates/Change Documentation Location.md
index 623d1597744..36678c44d70 100644
--- a/.gitlab/merge_request_templates/Change Documentation Location.md
+++ b/.gitlab/merge_request_templates/Change Documentation Location.md
@@ -24,7 +24,7 @@ https://docs.gitlab.com/ee/development/documentation/index.html#move-or-rename-a
       specifically under the `app/views/` and `ee/app/views` (for GitLab EE) directories.
 - [ ] Make sure to add [`redirect_from`](https://docs.gitlab.com/ee/development/documentation/index.html#redirections-for-pages-with-disqus-comments)
       to the new document if there are any Disqus comments on the old document thread.
-- [ ] Update the link in `features.yml` (if applicable)
+- [ ] Update the link in `features.yml` (if applicable).
 - [ ] Assign one of the technical writers for review.
 
 /label ~documentation ~"Technical Writing"
diff --git a/.gitlab/merge_request_templates/Deprecations.md b/.gitlab/merge_request_templates/Deprecations.md
index 1449246b9bc..1cadf54ff1d 100644
--- a/.gitlab/merge_request_templates/Deprecations.md
+++ b/.gitlab/merge_request_templates/Deprecations.md
@@ -1,6 +1,6 @@
 <!-- Set the correct label and milestone using autocomplete for guidance. Please @mention only the DRI(s) for each stage or group rather than an entire department. -->
 
-/label ~"release post" ~"release post item" ~"Technical Writing" ~"devops::" ~"group::"
+/label ~"release post" ~"release post item" ~"Technical Writing" ~"devops::" ~"group::" ~"release post item::deprecation"
 /milestone %
 /assign `@PM`
 
@@ -41,7 +41,7 @@ They are frequently updated, and everyone should make sure they are aware of the
 
 ## Reviewers
 
-When the content is ready for review, it must be reviewed by Technical Writer and Engineering Manager, but can also be reviewed by
+When the content is ready for review, it must be reviewed by a Technical Writer and Engineering Manager, but can also be reviewed by
 Product Marketing, Product Design, and the Product Leaders for this area. Please use the
 [Reviewers for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/getting_started#reviewer)
 feature for all reviews. Reviewers will then `approve` the MR and remove themselves from Reviewers when their review is complete.
@@ -61,7 +61,7 @@ as needed, @ message the PM to inform them the first review is complete, and rem
 yourself as a reviewer if it's not ready for merge yet.
 
 <details>
-<summary>Expand for Details </summary>
+<summary>Expand for Details</summary>
 
 - [ ] Title:
   - Length limit: 7 words (not including articles or prepositions).
diff --git a/.gitlab/merge_request_templates/Documentation.md b/.gitlab/merge_request_templates/Documentation.md
index 893ae7b93b5..d3ea9682d34 100644
--- a/.gitlab/merge_request_templates/Documentation.md
+++ b/.gitlab/merge_request_templates/Documentation.md
@@ -8,7 +8,7 @@
 
 ## Author's checklist
 
-- [ ] Consider taking [the GitLab Technical Writing Fundamentals course](https://gitlab.edcast.com/pathways/ECL-02528ee2-c334-4e16-abf3-e9d8b8260de4)
+- [ ] Consider taking [the GitLab Technical Writing Fundamentals course](https://gitlab.edcast.com/pathways/ECL-02528ee2-c334-4e16-abf3-e9d8b8260de4).
 - [ ] Follow the:
   - [Documentation process](https://docs.gitlab.com/ee/development/documentation/workflow.html).
   - [Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/).
@@ -20,7 +20,6 @@
 
 If you are only adding documentation, do not add any of the following labels:
 
-- `~"type::feature"`
 - `~"frontend"`
 - `~"backend"`
 - `~"type::bug"`
@@ -41,8 +40,8 @@ Documentation-related MRs should be reviewed by a Technical Writer for a non-blo
     - [ ] The headings (other than the page title) should be active. Instead of `Configuring GDK`, say something like `Configure GDK`.
     - [ ] Any task steps should be written as a numbered list.
     - If the content still needs to be edited for topic types, you can create a follow-up issue with the ~"docs-technical-debt" label.
-- [ ] Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
+- [ ] Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
 - [ ] Ensure a release milestone is set.
 
-/label ~documentation
+/label ~documentation ~"type::maintenance"
 /assign me
diff --git a/.gitlab/merge_request_templates/New End To End Test.md b/.gitlab/merge_request_templates/New End To End Test.md
index 9ecf8999f66..4c42b324553 100644
--- a/.gitlab/merge_request_templates/New End To End Test.md
+++ b/.gitlab/merge_request_templates/New End To End Test.md
@@ -4,7 +4,7 @@
 Please link to the respective test case in the testcases project
 -->
 
-### Check-list
+### Checklist
 
 - [ ] Confirm the test has a [`testcase:` tag linking to an existing test case](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html#link-a-test-to-its-test-case-issue) in the test case project.
 - [ ] Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
@@ -15,7 +15,7 @@ Please link to the respective test case in the testcases project
 - [ ] Verify the tags to ensure it runs on the desired test environments.
 - [ ] If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
 - [ ] (If applicable) Create a follow-up issue to document [the special setup](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/running_tests_that_require_special_setup.html) necessary to run the test: ISSUE_LINK
-- [ ] If the test requires an admin's personal access token, ensure that the test passes on your local with and without the `GITLAB_QA_ADMIN_ACCESS_TOKEN` provided.
+- [ ] If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the `GITLAB_QA_ADMIN_ACCESS_TOKEN` provided.
 
 <!-- Base labels. -->
 /label ~"Quality" ~"QA" ~test
diff --git a/.gitlab/merge_request_templates/New Static Analysis Check.md b/.gitlab/merge_request_templates/New Static Analysis Check.md
index 66041a784e8..6ad56cd5cd0 100644
--- a/.gitlab/merge_request_templates/New Static Analysis Check.md
+++ b/.gitlab/merge_request_templates/New Static Analysis Check.md
@@ -12,20 +12,20 @@ Please describe the proposal and add a link to the source (for example, http://w
 ### Check-list
 
 - [ ] Make sure this MR enables a static analysis check rule for new usage but
-  ignores current offenses
-- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`)
+  ignores current offenses.
+- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
 - [ ] If there is a choice to make between two potential styles, set up an emoji vote in the MR:
   - CHOICE_A: :a:
   - CHOICE_B: :b:
-  - Vote yourself for both choices so that people know these are the choices
-- [ ] The MR doesn't have significant objections, and is getting a majority of :+1: vs :-1: (remember that [we don't need to reach a consensus](https://about.gitlab.com/handbook/values/#collaboration-is-not-consensus))
-- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice)
-- [ ] (If applicable) Update the MR with the chosen style
+  - Vote for both choices, so they are visible to others.
+- [ ] The MR doesn't have significant objections, and is getting a majority of :+1: vs :-1: (remember that [we don't need to reach a consensus](https://about.gitlab.com/handbook/values/#collaboration-is-not-consensus)).
+- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice).
+- [ ] (If applicable) Update the MR with the chosen style.
 - [ ] Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
-- [ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual
+- [ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual.
 - [ ] Once approved and merged by a maintainer, mention it again:
-  - [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`)
-  - [ ] (Optional depending on the impact of the change) In the Engineering Week in Review
+  - [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
+  - [ ] (Optional depending on the impact of the change) In the Engineering Week in Review.
 
 /label ~"Engineering Productivity" ~"development guidelines" ~"static code analysis"
 
diff --git a/.gitlab/merge_request_templates/Pipeline Configuration.md b/.gitlab/merge_request_templates/Pipeline Configuration.md
index 62210028c18..a0b8d1cb8e4 100644
--- a/.gitlab/merge_request_templates/Pipeline Configuration.md
+++ b/.gitlab/merge_request_templates/Pipeline Configuration.md
@@ -9,7 +9,7 @@
 
 <!-- Link related issues below. -->
 
-## Check-list
+## Checklist
 
 ### Pre-merge
 
diff --git a/.gitlab/merge_request_templates/Quarantine End to End Test.md b/.gitlab/merge_request_templates/Quarantine End to End Test.md
index 4caebb7f1bb..a8d2378eee0 100644
--- a/.gitlab/merge_request_templates/Quarantine End to End Test.md
+++ b/.gitlab/merge_request_templates/Quarantine End to End Test.md
@@ -19,14 +19,14 @@ the noise (due to constantly failing tests, flaky tests, and so on) so that new
   - [ ] [Code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
   - [ ] [Style guides](https://docs.gitlab.com/ee/development/contributing/style_guides.html)
 - [ ] Quarantine test check-list
-  - [ ] Follow the [Quarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests).
-  - [ ] Confirm the test has a [`quarantine:` tag with the specified quarantine type](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantined-test-types).
+  - [ ] Follow the [Quarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#quarantining-tests).
+  - [ ] Confirm the test has a [`quarantine:` tag with the specified quarantine type](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#quarantined-test-types).
   - [ ] Note if the test should be [quarantined for a specific environment](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/execution_context_selection.html#quarantine-a-test-for-a-specific-environment).
   - [ ] (Optionally) In case of an emergency (e.g. blocked deployments), consider adding labels to pick into auto-deploy (~"Pick into auto-deploy" ~"priority::1" ~"severity::1").
 - [ ] Dequarantine test check-list
-  - [ ] Follow the [Dequarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#dequarantining-tests).
+  - [ ] Follow the [Dequarantining Tests guide](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#dequarantining-tests).
   - [ ] Confirm the test consistently passes on the target GitLab environment(s).
-    - [ ] (Optionally) [Trigger a manual GitLab-QA pipeline](https://about.gitlab.com/handbook/engineering/quality/guidelines/tips-and-tricks/#running-gitlab-qa-pipeline-against-a-specific-gitlab-release) against a specific GitLab environment using the `RELEASE` variable from the `package-and-qa` job of the current merge request.
+    - [ ] (Optionally) [Trigger a manual GitLab-QA pipeline](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/tips-and-tricks/#running-gitlab-qa-pipeline-against-a-specific-gitlab-release) against a specific GitLab environment using the `RELEASE` variable from the `package-and-qa` job of the current merge request.
 - [ ] To ensure a faster turnaround, ask in the `#quality` Slack channel for someone to review and merge the merge request, rather than assigning it directly.
 
 <!-- Base labels. -->
diff --git a/.gitlab/merge_request_templates/Security Release.md b/.gitlab/merge_request_templates/Security Release.md
index 7684546b91c..bfa80d65018 100644
--- a/.gitlab/merge_request_templates/Security Release.md
+++ b/.gitlab/merge_request_templates/Security Release.md
@@ -20,13 +20,13 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
   - [ ] Assign to a reviewer and maintainer, per our [Code Review process].
   - [ ] Ensure it's approved according to our [Approval Guidelines].
   - [ ] Ensure it's approved by an AppSec engineer.
-    - Please see the security release [Code reviews and Approvals](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals) documentation for details on which AppSec team member to ping for approval.
+    - Please see the security release [Code reviews and Approvals] documentation for details on which AppSec team member to ping for approval.
     - Trigger the [`package-and-qa` build]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
-- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`)
+- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`).
   - [ ] Milestone is set to the version this backport applies to. A closed milestone can be assigned via [quick actions].
   - [ ] Ensure it's approved by a maintainer.
 
-**Note:** Reviewer/maintainer should not be a Release Manager
+**Note:** Reviewer/maintainer should not be a Release Manager.
 
 ## Maintainer checklist
 
@@ -39,6 +39,7 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 [quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
 [CHANGELOG entry]: https://docs.gitlab.com/ee/development/changelog.html#overview
 [Code Review process]: https://docs.gitlab.com/ee/development/code_review.html
+[Code reviews and Approvals]: (https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals)
 [Approval Guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
 [Canonical repository]: https://gitlab.com/gitlab-org/gitlab
 [`package-and-qa` build]: https://docs.gitlab.com/ee/development/testing_guide/end_to_end/#using-the-package-and-qa-job