Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42

9 files changed, 186 insertions, 59 deletions

diff --git a/.gitlab/issue_templates/Audit Event Proposal.md b/.gitlab/issue_templates/Audit Event Proposal.md
new file mode 100644
index 00000000000..7a5408ca1f2
--- /dev/null
+++ b/.gitlab/issue_templates/Audit Event Proposal.md
@@ -0,0 +1,13 @@
+<!-- Audit Event documentation: See https://docs.gitlab.com/ee/administration/audit_events.html -->
+
+## Audit need
+
+<!-- Describe the real-world use case for the audit event you want to introduce, and explain the closest thing that GitLab already captures. -->
+
+## Proposal
+
+<!-- Describe the audit event you are proposing should be added, including any details of what should be captured, how, and why. -->
+
+/label ~"Category:Audit Events"
+/label ~"feature"
+/label ~"group::compliance"
diff --git a/.gitlab/issue_templates/Experiment Idea.md b/.gitlab/issue_templates/Experiment Idea.md
new file mode 100644
index 00000000000..2693f09e062
--- /dev/null
+++ b/.gitlab/issue_templates/Experiment Idea.md
@@ -0,0 +1,48 @@
+## Experiment summary
+
+We believe that... {describe your hypothesis in one sentence}
+
+To verify that, we will... {describe your test in one sentence}
+
+And we’ll measure the impact on... {metrics}
+
+## Hypothesis
+<!-- The hypothesis represents the high-level thought process in creating the experiment but does not need to be proven in one experiment. For example, you could have a hypothesis that “users would benefit from more easily being able to start a trial” and your first experiment could fail, that doesn’t void your hypothesis only indicates you may need to think of a new iterative experiment that would still align with your hypothesis. -->
+
+## Business problem
+<!-- Where the hypothesis is focused on the user/customer, the business problem represents why/how an experiment in this area could positively impact the business. For example, trials represent a significant way for GitLab to produce valuable leads for the sales team. -->
+
+## Supporting data
+<!-- Why should we run this experiment? What’s the potential impact? Show supporting data that’s both qualitative and quantitative. Quantitative example, we generate 30,000 sign ups a month and 900 trails within 90 days (3%) with a close rate of 10% and an IACV of $400.  If we’re able to increase our trial volume by 10% percent (990 trials a month) we will generate an additional $3,600 IACV if our close rates remain constant. Qualitative example, in searching Zendesk I was able to find 10 support tickets in the last 30 days that referenced difficulties with starting a trial due to the user not being an admin. (all numbers are hypothetical and only listed for the purpose of having an example) -->
+
+## Expected outcome
+<!-- What is the expected outcome of this experiment, what metric are we trying to move? Are there any metrics we know we do not want to impact? For example, we want to impact IACV by increasing the rate at which users start trials within 30 days but we also want to ensure we don't increase the churn rate for users who've recently purchased. -->
+
+## Experiment design & implementation
+<!-- What is the experiment we’re going to run? How long do you believe it will need to run to reach significance? For example, our experiment would be to allow non-admins to request a trial through their admin, to detect a 10% change from our baseline conversion rate we’ll need a sample size of 57,000 (source Optimizely), with our current sign up rate of 30,000 a month this experiment will need to run for ~2 months. (all numbers are hypothetical and only listed for the purpose of having an example) -->
+
+## ICE score
+
+<!-- See https://about.gitlab.com/handbook/product/growth/#growth-ideation-and-prioritization -->
+
+| Impact | Confidence | Ease | Score |
+| ------ | ------ | ------ | ------ |
+| value 1 |  value 2 |  value 3 | Average(1:3) |
+
+## Known assumptions
+<!-- This is an area to call out known assumptions in the experiment, this is especially helpful for any future colleagues that join the team so they understand other potential influences and how they were accounted for. This section is also helpful in framing possible scenarios and to keep the door open for the next steps. For example, we’re hoping our experiment will increase the number of people that start a trial but we’re assuming the conversion rate to paid and IACV will remain the same. This is a known assumption and depending on the results of the experiment could impact the direction we take on any future iterations. -->
+
+## Results, lessons learned, next steps
+<!-- What were the results of the experiment? Was the experiment a success or a failure? Based on the results should we remove the code or advocate that it become a permanent part of the experience for all users? Are there future experiments the team is going to run based off these results (include a link to new issue)? For example, our trial experiment was successful we increased the trial create rate by 10% but we saw a 1% drop in our close rate which means our net impact on IACV was negative $360 (990 * 0.09 * 400 compared tot he control of 900 * 0.1 * 400). Our next experiment (link) will focus on increasing the value once a user starts a trial. (all numbers are hypothetical and only listed for the purpose of having an example) -->
+
+
+## Checklist
+
+* [ ] Fill in the experiment summary and write more about the details of the experiment in the rest of the issue description. Some of these may be filled in through time (the "Result, learnings, next steps" section for example) but at least the experiment summary should be filled in right from the start.
+* [ ] Add the label of the `group::` that will work on this experiment (if known).
+* [ ] Mention the Product Manager, Engineering Manager, and at least one Product Designer from the group that owns the part of the product that the experiment will affect.
+* [ ] Fill in the values in the [ICE score table](#ice-score) ping other team members for the values you aren’t confident about (i.e. engineering should almost always fill out the ease section). Add the ~"ICE Score Needed" label to indicate that the score is incomplete.
+* [ ] Replace the ~"ICE Score Needed" with an ICE low/medium/high score label once all values in the ICE table have been added.
+* [ ] Mention the [at]gitlab-core-team team and ask for their feedback.
+
+/label ~"workflow::validation backlog" ~"experiment idea"
diff --git a/.gitlab/issue_templates/Feature Flag Removal.md b/.gitlab/issue_templates/Feature Flag Removal.md
new file mode 100644
index 00000000000..c061ab8516c
--- /dev/null
+++ b/.gitlab/issue_templates/Feature Flag Removal.md
@@ -0,0 +1,28 @@
+<!-- Title suggestion: [Feature flag] Remove FEATURE_FLAG_NAME -->
+
+## Feature
+
+The `:feature_name` feature flag was previously [enabled by default](URL) and should be removed.
+
+## Owners
+
+- Group: ~"group::GROUP_NAME"
+- Slack channel: `#g_GROUP_NAME`
+- DRI: USERNAME
+- PM: USERNAME
+
+**Removal**
+
+This is an __important__ phase, that should be either done in the next Milestone or as soon as possible. For the cleanup phase, please follow our documentation on how to  [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up).
+
+- [ ] Remove `:feature_name` feature flag
+    - [ ] Remove all references to the feature flag from the codebase
+    - [ ] Remove the YAML definitions for the feature from the repository
+    - [ ] Create a Changelog Entry
+
+- [ ] Clean up the feature flag from all environments by running this chatops command in `#production` channel `/chatops run feature delete some_feature`.
+
+- [ ] Close this issue after the feature flag is removed from the codebase.
+
+/label ~"feature flag" ~"technical debt"
+/assign DRI
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index a67d0f4e31a..f07604d2d3d 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -1,11 +1,11 @@
 <!-- Title suggestion: [Feature flag] Enable description of feature -->
 
-## Feature
+## Summary
 
-This feature uses the `:feature_name` feature flag!
+This issue is to rollout [the feature](ISSUE LINK) on production,
+that is currently behind the `<feature-flag-name>` feature flag.
 
 <!-- Short description of what the feature is about and link to relevant other issues. -->
-- [Issue Name](ISSUE LINK)
 
 ## Owners
 
@@ -26,14 +26,15 @@ Are there any other stages or teams involved that need to be kept in the loop?
 
 ## The Rollout Plan
 
-- Partial Rollout on GitLab.com with beta groups
+- Partial Rollout on GitLab.com with testing groups
 - Rollout on GitLab.com for a certain period (How long)
 - Percentage Rollout on GitLab.com
 - Rollout Feature for everyone as soon as it's ready
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? Sentry errors reports can also be useful to review -->
 
-**Beta Groups/Projects:**
+## Testing Groups/Projects/Users
+
 <!-- If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example. -->
 
 - `gitlab-org/gitlab` project
@@ -55,60 +56,97 @@ Are there any other stages or teams involved that need to be kept in the loop?
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
 
-## Rollout Timeline
-
-<!-- Please check which steps are needed and remove those which don't apply -->
-
-**Initial Rollout**
-
-*Preparation Phase*
-- [ ] Enable on staging (`/chatops run feature set feature_name true --staging`)
-
-- [ ] Test on staging
-
-- [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default))
-
-- [ ] Announce on the issue an estimated time this will be enabled on GitLab.com
-
-*Partial Rollout Phase*
-- [ ] Enable on GitLab.com for individual groups/projects listed above and verify behaviour (`/chatops run feature set --project=gitlab-org/gitlab feature_name true`)
-
-- [ ] Verify behaviour (See Beta Groups) and add details with screenshots as a comment on this issue
-
-- [ ] If it is possible to perform an incremental rollout, this should be preferred. Proposed increments are: `10%`, `50%`, `100%`. Proposed minimum time between increments is 15 minutes.
-  - When setting percentages, make sure that the feature works correctly between feature checks. See https://gitlab.com/gitlab-org/gitlab/-/issues/327117 for more information
-  - For actor-based rollout: `/chatops run feature set feature_name 10 --actors`
-  - For time-based rollout: `/chatops run feature set feature_name 10`
-
-- [ ] Make the feature flag enabled by default i.e. Change `default_enabled` to `true`
-
-- [ ] Cross post chatops slack command to `#support_gitlab-com` ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#where-to-run-commands)) and in your team channel
-
-
-**Cleanup**
-
-This is an __important__ phase, that should be either done in the next Milestone or as soon as possible. For the cleanup phase, please follow our documentation on how to  [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up).
-
-<!-- The checklist here is to keep track of it's status for stakeholders -->
-- [ ] Announce on the issue that the flag has been enabled
-
-- [ ] Remove `:feature_name` feature flag
-    - [ ] Remove all references to the feature flag from the codebase
-    - [ ] Remove the YAML definitions for the feature from the repository
-    - [ ] Create a Changelog Entry
-
-- [ ] Clean up the feature flag from all environments by running this chatops command in `#production` channel `/chatops run feature delete some_feature`.
-
-**Final Step**
-
-- [ ] Close this rollout issue for the feature flag after the feature flag is removed from the codebase.
+## Rollout Steps
+
+### Rollout on non-production environments
+
+- [ ] Ensure that the feature MRs have been deployed to non-production environments.
+    - [ ] `/chatops run auto_deploy status <merge-commit-of-your-feature>`
+- [ ] Enable the feature globally on non-production environments.
+    - [ ] `/chatops run feature set <feature-flag-name> true --dev`
+    - [ ] `/chatops run feature set <feature-flag-name> true --staging`
+- [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
+
+### Preparation before production rollout
+
+- [ ] Ensure that the feature MRs have been deployed to both production and canary.
+    - [ ] `/chatops run auto_deploy status <merge-commit-of-your-feature>`
+- [ ] Check if the feature flag change needs to be accompanied with a
+  [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
+  Cross link the issue here if it does.
+- [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
+  If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
+- [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default)).
+- [ ] Announce on [the feature issue](ISSUE LINK) an estimated time this will be enabled on GitLab.com.
+- [ ] If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), enable it on GitLab.com for [testing groups/projects](#testing-groupsprojectsusers).
+    - [ ] `/chatops run feature set --<actor-type>=<actor> <feature-flag-name> true`
+- [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
+
+### Global rollout on production
+
+- [ ] [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature.
+  - If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform **actor-based** rollout.
+    - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
+  - If the feature flag in code does **NOT** have [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform time-based rollout (**random** rollout).
+    - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage>`
+  - Enable the feature globally on production environment.
+    - [ ] `/chatops run feature set <feature-flag-name> true`
+- [ ] Announce on [the feature issue](ISSUE LINK) that the feature has been globally enabled.
+- [ ] Cross-post chatops slack command to `#support_gitlab-com`.
+  ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)) and in your team channel
+- [ ] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).
+
+### (Optional) Release the feature with the feature flag
+
+If you're still unsure whether the feature is [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
+but want to release it in the current milestone, you can change the default state of the feature flag to be enabled.
+To do so, follow these steps:
+
+- [ ] Create a merge request with the following changes. Ask for review and merge it.
+    - [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
+    - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
+- [ ] Ensure that the above MR has been deployed to both production and canary.
+      If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
+      the feature can be officially announced in a release blog post.
+    - [ ] `/chatops run auto_deploy status <merge-commit>`
+- [ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
+
+**WARNING:** This approach has the downside that it makes it difficult for us to
+[clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) the flag.
+For example, on-premise users could disable the feature on their GitLab instance. But when you
+remove the flag at some point, they suddenly see the feature as enabled and they can't roll it back
+to the previous behavior. To avoid this potential breaking change, use this approach only for urgent
+matters.
+
+### Release the feature
+
+After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
+the [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up)
+should be done as soon as possible to permanently enable the feature and reduce complexity in the
+codebase.
+
+<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
+- [ ] Create a merge request to remove `<feature-flag-name>` feature flag. Ask for review and merge it.
+    - [ ] Remove all references to the feature flag from the codebase.
+    - [ ] Remove the YAML definitions for the feature from the repository.
+    - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
+- [ ] Ensure that the above MR has been deployed to both production and canary.
+      If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
+      the feature can be officially announced in a release blog post.
+    - [ ] `/chatops run auto_deploy status <merge-commit>`
+- [ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
+- [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel:
+    - [ ] `/chatops run feature delete <feature-flag-name> --dev`
+    - [ ] `/chatops run feature delete <feature-flag-name> --staging`
+    - [ ] `/chatops run feature delete <feature-flag-name>`
+- [ ] Close this rollout issue.
 
 ## Rollback Steps
 
 - [ ] This feature can be disabled by running the following Chatops command:
 
 ```
-/chatops run feature set --project=gitlab-org/gitlab feature_name false
+/chatops run feature set <feature-flag-name> false
 ```
 
 /label ~"feature flag"
diff --git a/.gitlab/issue_templates/Basic Proposal.md b/.gitlab/issue_templates/Feature Proposal - basic.md
index 8d47e87f8a3..099243c05ca 100644
--- a/.gitlab/issue_templates/Basic Proposal.md
+++ b/.gitlab/issue_templates/Feature Proposal - basic.md
@@ -4,7 +4,7 @@
 
 <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
 
-<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
+<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
 
 /label ~"group::" ~"section::"  ~"Category::" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate" 
 
diff --git a/.gitlab/issue_templates/Lean Feature Proposal.md b/.gitlab/issue_templates/Feature Proposal - lean.md
index 828d5161269..9dd4bdc6b22 100644
--- a/.gitlab/issue_templates/Lean Feature Proposal.md
+++ b/.gitlab/issue_templates/Feature Proposal - lean.md
@@ -14,14 +14,14 @@
 
 
 
-/label ~"feature" ~"group::" ~"section::"  ~"Category::" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"
+/label ~"feature" ~"group::" ~"section::"  ~"Category::" ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
 
 
 <!--- Use the following resources to find the appropriate labels:
 - https://gitlab.com/gitlab-org/gitlab/-/labels
 - https://about.gitlab.com/handbook/product/categories/features/
 
-Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
+Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
 
 Other sections to consider adding: 
 
diff --git a/.gitlab/issue_templates/Feature proposal.md b/.gitlab/issue_templates/Feature proposal - detailed.md
index 72ee11e6f96..9b72ed5a01c 100644
--- a/.gitlab/issue_templates/Feature proposal.md
+++ b/.gitlab/issue_templates/Feature proposal - detailed.md
@@ -111,7 +111,7 @@ Use the following resources to find the appropriate labels:
 - https://about.gitlab.com/handbook/product/categories/features/
 -->
 /label ~devops:: ~group: ~Category:
-/label  ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"
+/label  ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
 /label ~feature
 /label ~documentation
 /label ~direction
diff --git a/.gitlab/issue_templates/Geo: Replicate a new Git repository type.md b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
index 6b2d732f246..feabef36f20 100644
--- a/.gitlab/issue_templates/Geo: Replicate a new Git repository type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
@@ -24,7 +24,7 @@ This issue is for implementing Geo replication and verification of Cool Widgets.
 
 For more background, see [Geo self-service framework](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo/framework.md).
 
-In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/geo.md).
+In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md).
 
 There are three main sections below. It is a good idea to structure your merge requests this way as well:
 
diff --git a/.gitlab/issue_templates/Geo: Replicate a new blob type.md b/.gitlab/issue_templates/Geo Replicate a new blob type.md
index 12fe6a6f5bb..b9e69d36ecc 100644
--- a/.gitlab/issue_templates/Geo: Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -24,7 +24,7 @@ This issue is for implementing Geo replication and verification of Cool Widgets.
 
 For more background, see [Geo self-service framework](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo/framework.md).
 
-In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/geo.md).
+In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md).
 
 There are three main sections below. It is a good idea to structure your merge requests this way as well: