Move organization owner role sync to CE
What does this MR do and why?
This is a pure relocation with no behaviour change. It moves the organization owner role sync workers, and the helpers they depend on, from EE into CE. It is split out of !255373 (merged) at reviewers' request: @skundapur asked for the CE move to land first, and @dlrussel pointed out that the organization_admin tuple is organization lifecycle data, not Artifact Registry data, so it does not belong under ee/. The follow-up fix MR (255373) will be rebased on top of this one once it merges.
What moves:
Authz::Organizations::GrantOwnerRoleWorker,RevokeOwnerRoleWorker, and theOwnerRoleSyncconcern move fromee/app/workerstoapp/workers, with their specs moving tospec/workersand their queue entries moving fromee/app/workers/all_queues.ymltoapp/workers/all_queues.yml. Queue names are unchanged, so there is no Sidekiq compatibility concern.- The promotion and removal hooks that enqueue these workers are inlined from the EE overrides
EE::Organizations::OrganizationUsers::UpdateServiceandDestroyServiceinto the CE services. The EE override files, theirprepend_modlines, and their EE specs are removed, with the examples merged into the CE specs. Authn::TokenExchange::TokenIssuermoves fromee/libtolib. Its signing key comes fromCloudConnector::CachingKeyLoader, which is EE-only, so the CE class raisesGitlab::AbstractMethodErrorfromsigning_jwk. A newEE::Authn::TokenExchange::TokenIssuermodule supplies the key viaprepend_mod.TokenIssuer.available?isfalsein CE andtruein EE; a missing Cloud Connector key keeps failing loudly in the worker, as on master. Its spec moves toee/spec/lib/ee/authn/token_exchange/because the key factory is EE, and a small CE spec, guarded to the FOSS run, asserts the CE defaults.- A new CE
Authz::Organizations::Roles.organization_admin_uuidresolves the Organization Administrator role id from the glaz roles catalogue.organization_adminis removed fromAuthz::ArtifactRegistry::Roles, which now holds only the four Artifact Registry roles, andTypes::Authz::ArtifactRegistry::RoleAssignmentTypeno longer special-cases it, so a platform role now resolves tonilwithout a drift warning. - A single enqueue gate,
Authz::Organizations::OwnerRoleSync.enabled?, checksAuthn::IamDataAccessService.configured?andTokenIssuer.available?, replacing the per-siteconfigured?checks. This means CE never enqueues jobs it cannot sign, while EE keeps the same enqueue conditions as master. A table-driven spec was added for this gate.
Worker names are unchanged, since renaming a Sidekiq worker needs a multi-release migration; that naming change has its own follow-up. Making owner-tuple propagation work on CE (a CE signing key, or the STS target state) is a separate follow-up.
References
- Follow-up fix MR (Artifact Registry owner role bootstrap), to be rebased on top of this one: !255373 (merged)
- Worker naming follow-up: #629378 (closed)
- CE propagation follow-up: #630491
Screenshots or screen recordings
Not applicable. This is a backend-only relocation with no UI changes.
How to set up and validate locally
Behaviour is unchanged. These steps confirm the same workers still fire from the same triggers, now defined in CE:
- With IAM data access configured (
iam_data_access_service.secret_fileingitlab.yml) and a Cloud Connector signing key present, promote an existing organization member to Owner using theorganizationUserUpdateGraphQL mutation. ConfirmAuthz::Organizations::GrantOwnerRoleWorkeris enqueued. - Remove an organization Owner, or demote them from Owner, using the corresponding mutation. Confirm
Authz::Organizations::RevokeOwnerRoleWorkeris enqueued. - On CE, repeat the same promotion or removal. Confirm neither worker is enqueued, since
Authz::Organizations::OwnerRoleSync.enabled?returnsfalse.
RuboCop is clean on all changed files. RSpec was not run locally because the test database cluster was unavailable in this environment; the MR pipeline runs the specs.
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.