Remove the artifact_registry_role_assignment feature flag

What does this MR do and why?

Removes the artifact_registry_role_assignment feature flag (EE, type wip, default off) and keeps the feature it gated running unconditionally.

The flag gated, per acting user:

  • the GraphQL mutations artifactRegistryRoleGrant, artifactRegistryRoleRevoke, artifactRegistryRoleBulkGrant, artifactRegistryRoleBulkRevoke
  • the GraphQL query artifactRegistryRoleAssignments
  • enqueuing Authz::Organizations::GrantOwnerRoleWorker and RevokeOwnerRoleWorker from the EE overrides of Organizations::OrganizationUsers::UpdateService and DestroyService. This is the owner role sync that grants organization owners the organization_admin role in IAM when they cross the owner boundary.

In the mutations and the resolver, the flag check is removed with nothing put in its place: the services already require an authenticated caller who is a member of the organization, IAM authorizes the write itself, and the grant service refuses when the organization has no Artifact Registry namespace. On an instance without IAM configured, the IAM client raises a configuration error that the services turn into a payload error ("The Artifact Registry service is unavailable."), so the mutations degrade to a clean error instead of behaving as if the feature does not exist.

In the two organization user services, the flag check is replaced by a new predicate, Authn::IamDataAccessService.configured?, which is true only when iam_data_access_service.secret_file is set in gitlab.yml. The gRPC host and port have working defaults (localhost:5005), so the secret file is the only setting that tells a deployment with IAM apart from one without. The IAM update client maps a missing configuration to an :unavailable reason, and the workers treat :unavailable as retryable (5 retries). Without this guard, every organization owner promotion, demotion, or removal on a self-managed instance without IAM would enqueue a job that raises and retries 5 times before giving up.

Why now: the flag was off on GitLab.com production, so a freshly onboarded organization's owners got no Artifact Registry role tuples and could not create repositories. The same flag blocked the grant mutations an admin could otherwise use to repair the organization by hand. The closed beta direction is to converge on a single org-scoped flag, artifact_registry_ui, with Authentication removing its user-scoped flags; the sibling flag gate_token_exchange_endpoint was already removed the same way, which this MR follows as a pattern (see References). The owner role sync workers were verified on staging: owner promotion made the organization_admin tuple effective in about 15 seconds, and demotion restored the deny.

Current flag state: enabled for two individual users on GitLab.com production via ChatOps; enabled globally on staging.

Out of scope, tracked as follow-up work: granting the owner role at Artifact Registry activation time for existing owners, and when an owner membership is created directly.

References

Screenshots or screen recordings

Not applicable. This is a backend-only change (GraphQL mutations/resolver and Ruby services); there is no UI change.

How to set up and validate locally

  1. No local feature-flag toggle is needed. The flag is deleted, so the mutations, query, and owner role sync run unconditionally whenever IAM is configured.
  2. RuboCop was run on all 16 changed Ruby files: no offenses.
  3. A Ruby 3.3 syntax check (ruby -c) was run on all changed files: passes.
  4. RSpec was not run locally. This checkout's test database lives in a Caproni Kubernetes cluster that is unreachable from this machine right now, so the MR pipeline is the verification for the updated specs: the five GraphQL request specs, the two organization user service specs, and the new table-driven Authn::IamDataAccessService.configured? spec.

After this MR merges, remove the flag from all environments:

/chatops run feature delete artifact_registry_role_assignment --dev --pre --staging --staging-ref --production

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code

Merge request reports

Loading
Loading