Add artifact registry client write methods

Fiona McCawleyrequested to merge
605079-ar-ruby-client-step-3 into 605077-ar-ruby-client-step-1

What does this MR do and why?

Add the artifact registry client write methods to ArtifactRegistry::Client:

  • create_repository(slug:, name:, format:, kind:, visibility:, description:) — POSTs the create body and returns the created Repository on 201.
  • update_repository(slug:, name:, visibility:, description:) — PATCHes only the mutable fields and returns the updated Repository on 200; a 404 is a genuine not-found (ApiError).
  • delete_repository(slug:, name:) — DELETEs and returns true on 204, and true on 404 (idempotent, mirroring Container Registry's delete_if_exists).

This is step 3 in the plan: https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/plans/monolith/2026-07-02-ar-ruby-client.md#step-3-write-methods--create_repository-update_repository-delete_repository

The three methods route through the shared request primitive and path-segment encoder introduced in step 1, so they inherit credential attachment (Authorization: Bearer), the X-Request-Id correlation header, the status → typed-exception mapping, and the retry configuration. Request bodies are compacted to the fields the caller provided (AR owns the defaults, and PATCH stays a partial update). Verb-specific retry falls out of the existing RETRY_OPTIONS: POST/PATCH are not retried on a transport failure, while the idempotent DELETE is retried once.

Like the rest of S02, this slice is dark: nothing calls the client yet (no resolver, no route), so it ships no feature flag and no changelog entry.

Stacked on step 1. This MR targets 605077-ar-ruby-client-step-1 (!244245 (merged)), not master, so the diff shows only the step 3 change (ee/lib/artifact_registry/client.rb plus its spec). Once !244245 (merged) merges, this branch will be rebased onto master and this MR retargeted.

How to set up and validate locally

Setup is the same as step 1 (!244245 (merged)): the caproni Artifact Registry dev rig, or a GDK Rails console against a running AR backend, with artifact_registry.api_url set under development in config/gitlab.yml.

Exercise the write methods from a Rails console, injecting a stand-in TokenExchange as in step 1:

token_exchange = Class.new(ArtifactRegistry::TokenExchange) do
  define_method(:token_for) { |_user, _slug| 'local-dev-not-a-secret' }
end.new
client = ArtifactRegistry::Client.new(current_user: nil, token_exchange: token_exchange)

# create -> Repository (201)
repo = client.create_repository(
  slug: 'gitlab-org', name: 'created-by-mr',
  format: 'container', kind: 'hosted', visibility: 'private'
)

# update mutable fields only -> Repository (200)
client.update_repository(slug: 'gitlab-org', name: 'created-by-mr', description: 'updated via client')

# delete -> true (204); deleting again is idempotent -> true (404)
client.delete_repository(slug: 'gitlab-org', name: 'created-by-mr')
client.delete_repository(slug: 'gitlab-org', name: 'created-by-mr')

The full behaviour matrix (status mappings, envelope parsing, per-verb retry, and path-segment encoding) is covered by the RSpec examples:

bundle exec rspec ee/spec/lib/artifact_registry/client_spec.rb

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.

Related to #605079 (closed)

Merge request reports