Geo: Derive RegistrableType union from REPLICATOR_CLASSES

What does this MR do and why?

The RegistrableType GraphQL union kept a hand-maintained GEO_REGISTRY_TYPES hash (registry class => registry type) that had to be updated for every new replicator. This derives it from Gitlab::Geo::REPLICATOR_CLASSES, so the replicator list is the single source of truth.

Each replicator already exposes registry_class and graphql_registry_type. A new Replicator.graphql_registerable? predicate (default true) is overridden to false in SupplyChainAttestationReplicator, which has no GraphQL registry type, so it stays out of the union.

  • Types::Geo::RegistrableType::GEO_REGISTRY_TYPES is derived, not hand-listed.
  • The blob replicator generator no longer patches the union, so there is one fewer hand-edited framework file per new replicator.
  • The conformance spec asserts the union maps exactly the graphql-registerable replicators.

This deliberately does not touch the GeoNodeType registry fields: those carry bespoke per-field descriptions and experiment milestones that are genuine API content, not mechanically derivable boilerplate, so generating them would either change the public schema or just relocate the strings.

Verification

  • bundle exec rake gitlab:graphql:compile_docs gitlab:graphql:generate_all_introspection_schemas produces no diff to the schema or docs: the derived union is identical to the previous hash (same 43 types), so the public GraphQL schema is unchanged.
  • Union type, resync/reverify mutation, generator, and conformance specs pass.
  • RuboCop clean.

Stacked MR

Stacked on !243966 (merged) (Derive REGISTRY_CLASSES). It targets that branch and will auto-retarget to master once !243966 (merged) merges.

Part of the SSF boilerplate reduction in #589925 (closed) (epic &20933).

🤖 Generated with Claude Code

Merge request reports

Loading