Connect the version list artifact read to the schema
What does this MR do and why?
Artifact Registry is an unreleased closed-beta feature. Its GraphQL schema is not complete, so the frontend fills gaps with Apollo local resolvers marked @client. This MR moves the artifact page closer to the real schema, and fixes a bug that broke the page on real data.
Schema binding
get_artifact.query.graphqlnow reads from the schema.@clientis gone fromimage(id:)andpackage(id:).- Version and manifest connections are not ready in the schema, so they stay local.
@clientmoved down, onto theversions/manifestsconnection itself. - That move removed a workaround: sort and paging arguments no longer need duplicating onto
package()/image(). Verified in the browser: the request now carries onlyorganizationId,name, andartifactId.
Mock layer
- Connections now build their rows from the artifact id, via
versionLadderFor(id)andmanifestLadderFor(id).versionsCountuses the same source, so the count matches the rows. - The local
imageresolver is deleted; nothing selects it that way any more. - The local
packageresolver stays, for the version detail page (commit 53e0e385), guarded so Apollo does not overwrite the schema's answer.
Bug fix and tests
artifactDisplayNameno longer joins the npmscopeontoname, fixing a duplicated heading like@acme/@acme/ui-components. This was already happening in the artifact list, which uses the same helper, so it is not a regression from this MR.- New schema-generated fixtures (Maven, npm, image) replace hand-written mocks in
version_list_spec.js. - A new
:jsfeature spec covers package and image headings and the not-found case, and runsbe_axe_cleanon the populated pages. - Two Storybook stories are fixed, since their handlers stopped matching the new resolvers.
The bug: the old mock resolver looked up an id in a list it generated itself, so a real id matched nothing, and the page showed "The Artifact Registry service is unavailable." Confirmed fixed on a live GDK.
No changelog trailer is added, since Artifact Registry is unreleased. The change touches no database, no migration, and nothing security sensitive.
References
- #618416 (closed): "Connect the version list view to the schema (monolith/S14 Step 25)"
This MR does not fully close the issue. The versions and manifests connections still need three schema arguments (sort on both, includeReferrers on manifests) and the version attribution fields (createdBy, project, gitCommitSha) before their @client directive can come off.
Screenshots or screen recordings
Both lists were checked in a browser against a live Artifact Registry, on these two routes:
- Version list:
/o/default/-/artifact_registry/acme/repositories/maven-repository/019ffef0-842d-7670-b4ea-f350acb3ca56 - Manifest list:
/o/default/-/artifact_registry/acme/repositories/oci-repository/01a05af1-ca65-776f-a351-2ccaa9ad51ef
Before and after images still need attaching to the table below.
| Before | After |
|---|---|
How to set up and validate locally
- Set up a GDK with Artifact Registry backed by real data.
- Visit a hosted Maven repository detail page.
- Click an artifact row.
- Confirm the version list loads and the heading shows the Maven coordinates (
groupId:artifactId). - Repeat steps 2 to 4 on a hosted OCI repository to reach the manifest list.
Before this change, the rows region showed the "Artifact Registry service is unavailable" alert instead of the version or manifest list.
Verification
- Jest: 52 suites, 1726 tests passed (
yarn jest ee/spec/frontend/packages_and_registries/artifact_registry). - RSpec: 8 examples, 0 failures (3 fixture examples, 5 feature examples, including the axe check).
- eslint, prettier, and rubocop: clean.
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.