Add latest changes from gitlab-org/gitlab@master

.gitlab/issue_templates/Feature Flag Roll Out.md

@@ -28,15 +28,14 @@ Note: Please make sure to run the chatops commands in the Slack channel that get
 
 ### Rollout on non-production environments
 
-- Verify the MR with the feature flag is merged to `master` and have been deployed to non-production environments with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
+- Verify the MR with the feature flag is merged to `master` and has been deployed to non-production environments with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
 <!-- Delete Incremental roll out if it is not relevant to this deploy -->
 - [ ] Deploy the feature flag at a percentage (recommended percentage: 50%) with `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors --dev --pre --staging --staging-ref`
 - [ ] Monitor that the error rates did not increase (repeat with a different percentage as necessary).
 <!-- End of block for deletes -->
 - [ ] Enable the feature globally on non-production environments with `/chatops run feature set <feature-flag-name> true --dev --pre --staging --staging-ref`
 - [ ] Verify that the feature works as expected.
-      The best environment to validate the feature in is [`staging-canary`](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary)
-      as this is the first environment deployed to. Make sure you are [configured to use canary](https://next.gitlab.com/).
+      The best environment to validate the feature in is [`staging-canary`](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary) as this is the first environment deployed to. Make sure you are [configured to use canary](https://next.gitlab.com/).
 - [ ] If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
    - See [`#e2e-run-staging` Slack channel](https://gitlab.enterprise.slack.com/archives/CBS3YKMGD) and look for the following messages:
       - test kicked off: `Feature flag <feature-flag-name> has been set to true on **gstg**`
@@ -46,7 +45,7 @@ For assistance with end-to-end test failures, please reach out via the [`#test-p
 
 ### Specific rollout on production
 
-For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
+For visibility, all `/chatops` commands that target production must be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
 and cross-posted (with the command results) to the responsible team's Slack channel.
 
 - Ensure that the feature MRs have been deployed to both production and canary with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
@@ -54,6 +53,7 @@ and cross-posted (with the command results) to the responsible team's Slack chan
   - For **project-actor**: `/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com <feature-flag-name> true`
   - For **group-actor**: `/chatops run feature set --group=gitlab-org,gitlab-com <feature-flag-name> true`
   - For **user-actor**: `/chatops run feature set --user=<gitlab-username-of-dri> <feature-flag-name> true`
+  - For **all internal users**: `/chatops run feature set --feature-group=gitlab_team_members <feature-flag-name> true`
 - [ ] Verify that the feature works for the specific actors.
 
 ### Preparation before global rollout
@@ -65,23 +65,17 @@ and cross-posted (with the command results) to the responsible team's Slack chan
 - [ ] 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 exists for the feature, and the [version history text](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#add-version-history-text) has been updated.
-- [ ] Leave a comment on [the feature issue](<feature-issue-link>) announcing estimated time when this feature flag will be enabled on GitLab.com.
 - [ ] Ensure that any breaking changes have been announced following the [release post process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes) to ensure GitLab customers are aware.
 - [ ] Notify the [`#support_gitlab-com` Slack channel](https://gitlab.slack.com/archives/C4XFU81LG) and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
-- [ ] Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.
 
 ### Global rollout on production
 
-For visibility, all `/chatops` commands that target production should be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
-and cross-posted (with the command results) to the responsible team's Slack channel (`#<slack-channel-of-dri-team>`).
+For visibility, all `/chatops` commands that target production must be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
+and cross-posted (with the command results) to the responsible team's Slack channel.
 
-- [ ] (Optional) [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature on production environment.
+- [ ] [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature on production.
   - Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net.
-  - Perform **actor-based** rollout: `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
-- [ ] Enable the feature globally on production environment: `/chatops run feature set <feature-flag-name> true`
-- [ ] Observe appropriate graphs on https://dashboards.gitlab.net and verify that services are not affected.
-- [ ] Leave a comment on [the feature issue](<feature-issue-link>) announcing that the feature has been globally enabled.
-- [ ] 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).
+- [ ] After the feature has been 100% enabled, wait for [at least one day before releasing the feature](#release-the-feature).
 
 ### (Optional) Release the feature with the feature flag
 
@@ -98,15 +92,15 @@ If you're still unsure whether the feature is [deemed stable](https://about.gitl
 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.
+- [ ] Create a merge request with the following changes.
     - [ ] If feature was enabled for various actors, ensure the feature has been enabled globally on production `/chatops run feature get <feature-flag-name>`. If the feature has not been globally enabled then enable the feature globally using: `/chatops run feature set <feature-flag-name> true`
     - [ ] 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`.
     - [ ] Decide [which changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
 - [ ] Ensure that the default-enabling MR has been included in the release package.
       If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
       the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
-- [ ] Consider cleaning up the feature flag from all environments by running these chatops command in `#production` channel. Otherwise these settings may override the default enabled: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
-- [ ] Close [the feature issue](<feature-issue-link>) to indicate the feature will be released in the current milestone.
+- [ ] After the default-enabling MR has been deployed, clean up the feature flag from all environments by running these chatops command in the `#production` channel: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
+- [ ] Close [the feature issue][<feature-issue-link>] to indicate the feature will be released in the current milestone.
 - [ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature).
 - [ ] (Optional) You can [create a separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) for scheduling the steps below to [Release the feature](#release-the-feature).
     - [ ] Set the title to "[Feature flag] Cleanup `<feature-flag-name>`".
@@ -120,21 +114,21 @@ To do so, follow these steps:
 
 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.
+should be done as soon as possible to permanently enable the feature and reduce
+complexity in the codebase.
 
-You can either [create a follow-up issue for Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) or use the checklist below in this same issue.
+You can either [create a follow-up issue for Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup)
+or use the checklist below in this same issue.
 
 <!-- The checklist here is to help stakeholders keep track of the feature flag status -->
 - [ ] Create a merge request to remove the `<feature-flag-name>` feature flag. Ask for review/approval/merge as usual. The MR should include the following changes:
     - 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 cleanup MR has been included in the release package.
       If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
       the feature can be officially announced in a release blog post: `/chatops run release check <merge-request-url> <milestone>`
-- [ ] Close [the feature issue](<feature-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 --pre --staging --staging-ref --production`
+- [ ] Close [the feature issue][<feature-issue-link>] to indicate the feature will be released in the current milestone.
+- [ ] Once the cleanup MR has been deployed to production, clean up the feature flag from all environments by running these chatops command in `#production` channel: `/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production`
 - [ ] Close this rollout issue.
 
 ## Rollback Steps

DUO_WORKFLOW_EXECUTOR_VERSION

@@ -1 +1 @@
-v0.0.7
+v0.0.9

doc/development/chatops_on_gitlabcom.md

@@ -59,5 +59,6 @@ To request access to ChatOps on GitLab.com:
 ## See also
 
 - [ChatOps Usage](../ci/chatops/index.md)
+- [Feature Flag Controls](feature_flags/controls.md)
 - [Understanding EXPLAIN plans](database/understanding_explain_plans.md)
 - [Feature Groups](feature_flags/index.md#feature-groups)

doc/development/feature_flags/controls.md

@@ -44,8 +44,7 @@ time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/ch
 
 For an up to date list of feature flag commands see
 [the source code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
-Note that all the examples in that file must be preceded by
-`/chatops run`.
+All the examples in that file must be preceded by `/chatops run`.
 
 If you get an error "Whoops! This action is not allowed. This incident
 will be reported." that means your Slack account is not allowed to
@@ -101,7 +100,7 @@ This depends on the feature and what sort of impact it might have.
 
 Guidelines:
 
-- Consider notifying `#support_gitlab-com` beforehand. So in case if the feature has any side effects on user experience, they can mitigate and disable the feature flag to reduce some impact.
+- Notify `#support_gitlab-com` beforehand. So in case if the feature has any side effects on user experience, they can mitigate and disable the feature flag to reduce some impact.
 - If the feature meets the requirements for creating a [Change Management](https://handbook.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process) issue, create a Change Management issue per [criticality guidelines](https://handbook.gitlab.com/handbook/engineering/infrastructure/change-management/#change-request-workflows).
 - For simple, low-risk, easily reverted features, proceed and [enable the feature in `#production`](#process).
 - For support requests to toggle feature flags for specific groups or projects, follow the process outlined in the [support workflows](https://handbook.gitlab.com/handbook/support/workflows/saas_feature_flags/).
@@ -200,12 +199,10 @@ incidents or in-progress change issues, for example:
 
 Before enabling a feature flag, verify that you are not violating any [Production Change Lock periods](https://handbook.gitlab.com/handbook/engineering/infrastructure/change-management/#production-change-lock-pcl) and are in compliance with the [Feature flags and the Change Management Process](https://handbook.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
 
-The following `/chatops` commands should be performed in the Slack
+The following `/chatops` commands must be performed in the Slack
 `#production` channel.
 
-When you begin to enable the feature, link to the relevant
-feature flag rollout issue within a Slack thread of the first `/chatops`
-command you make so people can understand the change if they need to.
+##### Percentage of time roll out
 
 To enable a feature for 25% of the time, run the following in Slack:
 
@@ -229,6 +226,8 @@ name of the feature.
 This command does *not* enable the feature for 25% of the total users.
 Instead, when the feature is checked with `enabled?`, it will return `true` 25% of the time.
 
+##### Percentage of actors roll out
+
 To enable a feature for 25% of actors such as users, projects, or groups,
 run the following in Slack:
 
@@ -307,7 +306,7 @@ generic namespace (including groups) use `--namespace`:
 /chatops run feature set --namespace=myusername some_feature true
 ```
 
-Note that actor-based gates are applied before percentages. For example, considering the
+Actor-based gates are applied before percentages. For example, considering the
 `group/project` as `gitlab-org/gitlab` and a given example feature as `some_feature`, if
 you run these 2 commands:
 

doc/development/feature_flags/index.md

@@ -413,8 +413,8 @@ command. For example:
 
 ## Toggle a feature flag
 
-See [rolling out changes](controls.md#rolling-out-changes) for more information about toggling
-feature flags.
+See [rolling out changes](controls.md#rolling-out-changes) for more information
+about toggling feature flags.
 
 ## Delete a feature flag
 
@@ -588,7 +588,7 @@ return unless Feature.enabled?(:feature_flag, project)
 project.update!(column: value)
 ```
 
-See [Feature flags in the development of GitLab](controls.md#process) for details on how to use ChatOps
+See [Use ChatOps to enable and disable feature flags](controls.md#process) for details on how to use ChatOps
 to selectively enable or disable feature flags in GitLab-provided environments, like staging and production.
 
 Flag state is not inherited from a group by its subgroups or projects.

qa/qa/specs/features/browser_ui/2_plan/project_wiki/project_based_file_upload_spec.rb

@@ -1,11 +1,7 @@
 # frozen_string_literal: true
 
 module QA
-  RSpec.describe 'Plan', :blocking, product_group: :knowledge,
-    quarantine: {
-      issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/409541',
-      type: :bug
-    } do
+  RSpec.describe 'Plan', :blocking, product_group: :knowledge do
     describe 'Testing project wiki file upload' do
       let(:initial_wiki) { create(:project_wiki_page) }
       let(:page_title) { 'Content Editor Page' }