Add GraphQL mutation to test a remote repository connection

Fiona McCawleyrequested to merge
618513-test-connection-mutation into master

What does this MR do and why?

Adds ArtifactRegistryRepositoryTestConnection, a GraphQL mutation that tests a remote repository's upstream connection. This is Step 4 of the monolith/S07 Phase 2 plan. It builds on Step 1, the client method, and Step 2, the remote settings read type and health-status enum, both merged. Step 3, the settings write path, is open in parallel and shares no file with this MR.

  • The mutation takes identity only, name, over the existing Mutations::ArtifactRegistry::Base. Mounted in ee/app/graphql/ee/types/mutation_type.rb as an experiment at milestone 19.4.
  • The payload carries four nullable fields: passed, whether the probe reached the upstream, httpStatus, the status the upstream answered with (null on a transport failure), and lastHealthStatus / lastHealthCheckedAt, the stored verdict as it reads after the probe.
  • A probe that ran answers with a verdict, so an unreachable upstream is a successful mutation carrying a not-reachable verdict, not a payload error. Error paths are reserved for outcomes where no verdict exists: Artifact Registry's 404, where the route does not exist on a hosted or virtual repository, which becomes a payload error, and its 500, where a probe ran but its verdict could not be recorded, which raises a top-level service-unavailable error. Both fall out of the existing shared error-rendering concern, so this adds no bespoke error mapping.

Everything ships behind the artifact_registry_ui feature flag, which is default off. No changelog entry, no user-facing strings, no user-visible change.

Why passed and httpStatus are named this way

These field names deliberately mirror Artifact Registry's own field names. This is intentional, not an oversight: the spec's Resolutions section names these fields the same way, citing api/openapi/v1.yaml, and the merged frontend groundwork (!251598 (merged)) chose them for the same reason, so that the later step connecting the UI to this schema renames nothing. Its typedef says so directly: "Artifact Registry's own field names, camelized the way graphql-ruby will expose them, so the step that mounts this mutation drops the @client directive and renames nothing." The spec also uses the word "reachable" descriptively elsewhere, but that is not the field name it settled on.

Scope note: a fourth file, beyond what the plan named

The plan scoped this step to three files. This MR also touches a fourth: ee/app/graphql/types/artifact_registry/health_status_enum.rb gains a shared class method, recognized_or_unknown, called from both this new mutation and the already-merged ee/app/graphql/types/artifact_registry/remote_settings_type.rb, which now calls it in place of the inline guard it had before.

The reason: Artifact Registry returns the health status as a raw string, and a value this schema does not declare would fail GraphQL enum coercion and fail the whole response, not just the field. That rule now has two call sites. Two copies of it could drift apart, so it is shared instead of duplicated. This was a deliberate, approved decision, not incidental scope creep. The read path's existing spec, remote_settings_type_spec.rb, still passes unchanged: 19 examples, 0 failures.

References

How to set up and validate locally

There is no UI to drive; the flag is off. Run the specs:

bundle exec rspec ee/spec/requests/api/graphql/mutations/artifact_registry/repositories/test_connection_spec.rb \
  ee/spec/graphql/types/artifact_registry/health_status_enum_spec.rb

22 examples, 0 failures. The request spec covers the reachable, not-reachable, 404, 500 and flag-off outcomes, plus a 401-upstream-still-passes case, a probe-versus-stored-verdict disagreement case, an unrecognized-status case, authorization cases, and two schema-shape assertions. The enum spec adds unit coverage of the new shared method.

The generated GraphQL artifacts, doc/api/graphql/reference/_index.md and public/-/graphql/introspection_result.json, were regenerated for the new mutation.

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.

Merge request reports