## Summary This issue is to roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/work_items/593858) on production, that is currently behind the `security_policy_eligible_projects_dropdown` feature flag. When enabled, the policy scope "specific projects" dropdown uses the `securityPolicyEligibleProjects` resolver (all projects under the root ancestors of every linked group), with cursor-based pagination and `ids`-based hydration of already-selected projects. When disabled, the existing linked-groups-projects dropdown (descendant projects only) is used. > **Multi-version note:** the `ids` argument on `securityPolicyEligibleProjects` was added in 19.1. > This flag must only be enabled once the backend fleet is guaranteed to be on ≥ 19.1, otherwise the > query is rejected by an older GraphQL schema. The flag-off path uses the pre-19.1 query and is safe. ## Owners - Most appropriate Slack channel to reach out to: `#g_srm_security_policies` - Best individual to reach out to: @arfedoro ## Expectations ### What are we expecting to happen? The eligible-projects dropdown surfaces all projects under the root ancestors of linked groups (not just descendants), pre-selected projects that are off the current page are hydrated by id, and pagination uses cursors. No change for users while the flag is off. ### What can go wrong and how would we detect it? - The broader project set / new resolver could be slow or error on large namespaces. - The by-ids hydration query could fail, surfacing a `projects-query-error` alert. - If enabled against a backend < 19.1, GraphQL rejects the query (the reason for the multi-version note). Detect via GraphQL/Rails error rates and latency on https://dashboards.gitlab.net. Rollback is disabling the flag, which reverts to the existing linked-groups dropdown with no data change. ## Rollout Steps Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command. ### Rollout on non-production environments - Verify the MR with the feature flag is merged to `master` and has been deployed to non-production environments with `/chatops gitlab run auto_deploy status <merge-commit-of-your-feature>` - [ ] Deploy the feature flag at a percentage (recommended percentage: 50%) with `/chatops gitlab run feature set security_policy_eligible_projects_dropdown <rollout-percentage> --actors --dev --pre --staging --staging-ref` - [ ] Monitor that the error rates did not increase (repeat with a different percentage as necessary). - [ ] Enable the feature globally on non-production environments with `/chatops gitlab run feature set security_policy_eligible_projects_dropdown true --dev --pre --staging --staging-ref` - [ ] Verify that the feature works as expected. ### Specific rollout on production - Ensure that the feature MRs have been deployed to both production and canary with `/chatops gitlab run auto_deploy status <merge-commit-of-your-feature>` - [ ] For **group-actor**: `/chatops gitlab run feature set --group=gitlab-org,gitlab-com security_policy_eligible_projects_dropdown true` - [ ] Verify that the feature works for the specific actors. ### Preparation before global rollout - [ ] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable. - [ ] Confirm the production backend fleet is on ≥ 19.1 before any global enablement (multi-version safety for the `ids` argument). - [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. - [ ] Ensure that documentation exists for the feature, and the version history text has been updated. - [ ] Notify the `#support_gitlab-com` Slack channel and your team channel. ### Global rollout on production - [ ] [Incrementally roll out](https://docs.gitlab.com/development/feature_flags/controls/#process) the feature on production. - Example: `/chatops gitlab run feature set security_policy_eligible_projects_dropdown <rollout-percentage> --actors`. - Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net. - [ ] After the feature has been 100% enabled, wait for at least one day before releasing the feature. ### Release the feature (cleanup) After the feature has been deemed stable, the cleanup should be done as soon as possible to permanently enable the feature and reduce complexity in the codebase. - [ ] Create a merge request to remove the `security_policy_eligible_projects_dropdown` feature flag. The MR should include the following changes: - Remove all references to the feature flag from the codebase. - Remove the old `LinkedGroupsProjectsDropdown` component, the `get_spp_linked_groups_projects.query.graphql` query, and their specs (the flag-off path). - Remove the YAML definition for the feature from the repository. - [ ] Ensure that the cleanup MR has been included in the release package. - [ ] Close [the feature issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/593858) to indicate the feature will be released. - [ ] 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 gitlab run feature delete security_policy_eligible_projects_dropdown --dev --pre --staging --staging-ref --production` - [ ] Close this rollout issue. ## Rollback Steps - [ ] This feature can be disabled on production by running the following Chatops command: ``` /chatops gitlab run feature set security_policy_eligible_projects_dropdown false ``` - [ ] Disable the feature flag on non-production environments: ``` /chatops gitlab run feature set security_policy_eligible_projects_dropdown false --dev --pre --staging --staging-ref ``` - [ ] Delete feature flag from all environments: ``` /chatops gitlab run feature delete security_policy_eligible_projects_dropdown --dev --pre --staging --staging-ref --production ``` --- Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/593858