## Summary This issue is to roll out [the feature](https://gitlab.com/gitlab-org/gitlab/-/work_items/369852) on production, that is currently behind the `container_registry_display_supported_platforms` feature flag. The feature renders a row of badges on the Container Registry tag details page listing each supported platform (OS/architecture) for multi-platform image indexes (Docker manifest lists and OCI image indexes). Platforms are fetched on-demand when a user expands a tag's details. UI-only, read-only — no data is written, no existing flows are modified. The flag is scoped by **project-actor**. ## Owners - Most appropriate Slack channel to reach out to: `#g_container-registry` - Best individual to reach out to: @fmccawley ## Expectations ### What are we expecting to happen? - For tags whose `mediaType` is `application/vnd.docker.distribution.manifest.list.v2+json` or `application/vnd.oci.image.index.v1+json`, expanding the tag in the Registry Explorer reveals a "Supported platforms" row with a badge per platform (e.g. `linux/amd64`, `linux/arm64`). - Non-index tags are unaffected — the row is not rendered. - The platform list is fetched lazily via the existing `getContainerRepositoryTagDetails` GraphQL query when "Show details" is clicked; no extra load on the index/list views. ### What can go wrong and how would we detect it? - **GraphQL/Registry pressure**: Lazy fetch may add load to the container registry API when users expand many tags. Watch tag-detail query latency and registry-service error rate. - **Rendering regressions**: An unexpectedly large platform list could blow out the row's layout. Verified on staging-canary before broader rollout. - **Auth edge cases**: The `before_action` pushes the flag on `:index` and `:show` only — `:destroy` is intentionally excluded. If users on enabled projects don't see badges, check the FF actor (project-scoped). - Dashboards: - [Container registry grafana dashboard](https://dashboards.gitlab.net/d/registry-main/registry3a-overview?from=now-6h/m&orgId=1&timezone=utc&to=now/m&var-PROMETHEUS_DS=mimir-gitlab-gprd&var-environment=gprd&var-stage=main) - [Kibana](https://log.gprd.gitlab.net/app/dashboards#/view/95a35e90-3e11-11eb-96c3-6b43c6e9bef8?_g=h@2294574) - GraphQL latency panel for `containerRepository.tags` ## 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>` - [x] Deploy the feature flag at a percentage (recommended percentage: 50%) with `/chatops gitlab run feature set container_registry_display_supported_platforms 50 --actors --dev --pre --staging --staging-ref` - [x] Monitor that the error rates did not increase (repeat with a different percentage as necessary). - [x] Enable the feature globally on non-production environments with `/chatops gitlab run feature set container_registry_display_supported_platforms 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/). - [ ] 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 container_registry_display_supported_platforms has been set to true on **gstg**` - test result: `This pipeline was triggered due to toggling of container_registry_display_supported_platforms feature flag` If you encounter end-to-end test failures and are unable to diagnose them, you may reach out to the [`#s_developer_experience` Slack channel](https://gitlab.enterprise.slack.com/archives/C07TWBRER7H) for assistance. Note that end-to-end test failures on `staging-ref` [don't block deployments](https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/#how-to-use-staging-ref). ### Before production rollout - [ ] If the change is significant and you wanted to announce in [#whats-happening-at-gitlab](https://gitlab.enterprise.slack.com/archives/C0259241C), it best to do it before rollout to `gitlab-org/gitlab-com`. ### Specific rollout on production 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 gitlab run auto_deploy status <merge-commit-of-your-feature>` - [ ] Enable for **project-actor** dogfooding scope: - `/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com container_registry_display_supported_platforms true` - [ ] Verify that the feature works on those projects by visiting their Container Registry page and expanding a multi-platform tag. ### Preparation before global rollout - [ ] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable. - [ ] Check if the feature flag change needs to be accompanied with a [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process). Cross link the issue here if it does. (Low-risk UI affordance — likely not required.) - [ ] 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](https://docs.gitlab.com/development/documentation/feature_flags/#add-history-text) has been updated. - [ ] Notify the [`#support_gitlab-com` Slack channel](https://gitlab.slack.com/archives/C4XFU81LG) and `#g_container-registry`. ### Global rollout on production 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. - [ ] [Incrementally roll out](https://docs.gitlab.com/development/feature_flags/controls/#process) the feature on production. - `/chatops gitlab run feature set container_registry_display_supported_platforms 25 --actors` - `/chatops gitlab run feature set container_registry_display_supported_platforms 50 --actors` - `/chatops gitlab run feature set container_registry_display_supported_platforms 75 --actors` - `/chatops gitlab run feature set container_registry_display_supported_platforms 100 --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). ### 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/development/feature_flags/controls/#cleaning-up) 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 `container_registry_display_supported_platforms` feature flag. The MR should include: - Remove the `push_frontend_feature_flag` call in `app/controllers/projects/registry/repositories_controller.rb`. - Remove the `glFeatureFlagsMixin` gate in `tags_list_row.vue` (currently gates `showManifestPlatforms`). - Delete `config/feature_flags/gitlab_com_derisk/container_registry_display_supported_platforms.yml`. - [ ] Ensure that the cleanup MR has been included in the release package. - [ ] Close [the feature issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/369852) 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 gitlab run feature delete container_registry_display_supported_platforms --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 container_registry_display_supported_platforms false ``` - [ ] Disable the feature flag on non-production environments: ``` /chatops gitlab run feature set container_registry_display_supported_platforms false --dev --pre --staging --staging-ref ``` - [ ] Delete feature flag from all environments: ``` /chatops gitlab run feature delete container_registry_display_supported_platforms --dev --pre --staging --staging-ref --production ```