## Summary Roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/work_items/627538) currently behind the `dependency_firewall_dashboard_v2` feature flag. The flag is checked for the root namespace (top-level group), so group actors are the rollout unit. It gates three things as they land: 1. Recording prevented packages on the enforcement path into the `dependency_firewall_prevented_packages` ledger (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253944, merged). A Redis buffer is flushed to PostgreSQL every 5 minutes. 1. The prevented-package GraphQL fields on `dependencyFirewallActivitySummary` (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253946, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253947). 1. The redesigned dashboard (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255295). The first release covers project dashboards; group dashboards keep the current view for now. The ledger has no history from before the flag is on, so counts start at enablement and the 7- and 30-day windows fill over time. Enable it for target namespaces as soon as the write path is deployed, even before the dashboard changes merge. - DRI: @arpitgogia - Team Slack channel: `#g_sscs-dependency-firewall` > [!note] > Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. > "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. > [Feature flag controls](https://docs.gitlab.com/development/feature_flags/controls/) · [Feature flag lifecycle](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle) ## Prerequisites 1. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/258702 merged (a `wip` flag cannot be enabled on GitLab.com). 2. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253944 deployed to GitLab.com production. Enabling at this point only starts recording; nothing is shown yet. 3. Before the flag is enabled for namespaces other than `gitlab-org`, the dashboard changes (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253946, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253947, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255295) should be merged, so users who get the flag see the finished project dashboard. ## What could go wrong? - Extra work on blocked and warned package requests: one Redis write per matched rule. Allowed requests are unaffected. Recording is best effort: any error is tracked and never breaks enforcement. - The flush worker writes to PostgreSQL every 5 minutes in batches of up to 1,000 rows; a backlog after an outage drains over several runs. - Once the dashboard changes merge, namespaces with the flag on see the redesigned dashboard. - Blast radius: namespaces with this flag enabled; package enforcement itself is not affected. - Watch: errors and duration for `Security::DependencyFirewall::FlushPreventedPackagesWriteBufferCronWorker`, exceptions from `Security::DependencyFirewall::EnforcementService` in error tracking, and the Events links below. ## Events - [Exceptions with dependency_firewall_dashboard_v2:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.exception.feature_flag_states.keyword:%22dependency_firewall_dashboard_v2:1%22'),columns:!(json.exception.class,json.exception.message,json.extra.workflow_id,json.meta.caller_id),sort:!(!(json.time,desc)))) - [Events with dependency_firewall_dashboard_v2:1](https://log.gprd.gitlab.net/app/discover#/?_g=(time:(from:now-1d,to:now))&_a=(index:'7092c4e2-4eb5-46f2-8305-a7da2edad090',query:(language:kuery,query:'json.feature_flag_states:%22dependency_firewall_dashboard_v2:1%22'),columns:!(json.meta.caller_id,json.feature_flag_states),sort:!(!(json.time,desc)))) - [Error rate and other graphs by modifying the examples in the Visualization Library](https://log.gprd.gitlab.net/app/visualize#/?_g=h@358d019&s=FF%20Observability) Feature Flag events are only logged by default for feature flags marked for the current or future milestones. To enable while the feature flag is active, see https://docs.gitlab.com/development/feature_flags/#logging ## Rollout Run all production `/chatops` in [`#production`](https://gitlab.slack.com/archives/C101F3796) and cross-post the results to `#g_sscs-dependency-firewall`. Background: [incremental rollout process](https://docs.gitlab.com/development/feature_flags/controls/#process), [feature actors](https://docs.gitlab.com/development/feature_flags/#feature-actors). **Non-production** ``` /chatops gitlab run feature set dependency_firewall_dashboard_v2 50 --actors --dev --pre --staging --staging-ref /chatops gitlab run feature set dependency_firewall_dashboard_v2 true --dev --pre --staging --staging-ref ``` **Production** (wait at least 15 minutes between steps, watch dashboards): First enable for `gitlab-org` to start collecting data and dogfood, then roll out by percentage of actors, since the flag is checked against the root group: ``` /chatops gitlab run feature set --group=gitlab-org dependency_firewall_dashboard_v2 true /chatops gitlab run feature set dependency_firewall_dashboard_v2 <percentage> --actors ``` ## Before global rollout Confirm the relevant gotchas before going to 100%. See [enabling a feature for GitLab.com](https://docs.gitlab.com/development/feature_flags/controls/#enabling-a-feature-for-gitlabcom): - [Docs + version history](https://docs.gitlab.com/development/documentation/feature_flags/) updated - [Breaking changes](https://docs.gitlab.com/development/documentation/release_notes/#deprecations-removals-and-breaking-changes) announced, if any - [Change management issue](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process) opened, if required - [External API consumers](https://docs.gitlab.com/development/feature_flags/#do-not-use-feature-flags-in-external-api-consumers) handled with a fail-open mechanism, if applicable ## Cleanup Remove the flag once [deemed stable](https://handbook.gitlab.com/handbook/product-development/how-we-work/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle). See [cleaning up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up). Track it here, or open a follow-up [Feature Flag Cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/new?description_template=Feature%20Flag%20Cleanup). Remove the flag and its YAML definition from the codebase, then: ``` /chatops gitlab run release check <merge-request-url> <milestone> /chatops gitlab run feature delete dependency_firewall_dashboard_v2 --dev --pre --staging --staging-ref --production ``` `beta` flags can be set to `default_enabled: true` before removal, which releases the feature to self-managed while keeping an off switch. ## Rollback ``` /chatops gitlab run feature set dependency_firewall_dashboard_v2 false # production /chatops gitlab run feature set dependency_firewall_dashboard_v2 false --dev --pre --staging --staging-ref # non-production /chatops gitlab run feature delete dependency_firewall_dashboard_v2 --dev --pre --staging --staging-ref --production # remove entirely ``` Disabling stops recording, so the ledger has a gap for that period, and hides the new dashboard; rows already recorded are kept.