MCM-30 — Registry Configuration for Artifact Delivery

← Back to MCM Nexus overview

As a Nexus Admin,
I want to configure the Artifact Registry's URL, repository path, and the registry's own admin credentials once in Nexus Settings, then fetch the versions published there on demand,
so that MCM-09 — Download MCM Installation Package and MCM-10 — Upgrade an MCM Instance via Nexus can fetch and serve real artefacts to customers, and MCM-33 — Release Catalog and Version Approval always knows what's actually available to review.

Acceptance Criteria

• A new Nexus-Admin-only Settings page lets the Nexus Admin configure the Artifact Registry connection: base URL, the registry's own admin username and admin password, and a Repository Path — the specific path within that registry where MCM version artefacts are published (e.g. mcm-releases/mcm). This is the same Sonatype Nexus Repository instance mcm-devops's build-and-publish pipeline already publishes to (NEXUS_DOCKER_URL/NEXUS_USERNAME/NEXUS_PASSWORD today) — not MCM Nexus, this portal; the shared name is a coincidence.
• The password field is write-only — never redisplayed in plaintext after save, same convention as MCM-03's Demo Instance settings.
• Nexus validates the configured connection (a lightweight auth check against the registry, plus confirming the Repository Path resolves to something) before saving, and shows a clear error if the URL, path, or credentials are wrong, rather than only failing later on a real customer download.
• Once the connection is saved, a separate "Fetch Versions" action lets the Nexus Admin pull the current list of every version published under the configured Repository Path. This is a manual, on-demand action, not an automatic background job — nothing appears in MCM-33 — Release Catalog and Version Approval's catalog until the Nexus Admin runs it. The Nexus Admin re-runs it whenever a new version or hotfix build has been published and needs to show up for review.
• Fetching only ever adds genuinely new versions to MCM-33's catalog (as PENDING) — it never changes the status of a version already marked APPROVED, REJECTED, or DEPRECATED.
• Until a Registry connection is configured, MCM-09's download action and MCM-10's upgrade endpoints are unavailable — the Nexus Admin sees a clear "Registry not configured" state pointing to this Settings page (mirrors how MCM-03 blocks approval without billing plans).
• Once configured, MCM-09's and MCM-10's endpoints use these credentials internally to call the real Artifact Registry — a raw-artifact fetch for the installer tarball, the equivalent path for upgrade bundles — and stream the actual artefact back. The customer/instance never receives registry credentials, only their own MCM App credential, unchanged from MCM-09/MCM-10's existing behavior.
• The Nexus Admin can update the Registry connection (including the Repository Path) at any time (e.g. credential rotation, moving to a new path); in-flight downloads use whichever credential was current when the artefact fetch began.

---

Technical Design

A new (admin)/settings/registry page stores the Artifact Registry's base URL, Repository Path, and the registry's own admin username/password in a new RegistryConfig entity (single row, password encrypted at rest, write-only from the frontend — same shape as MCM-03's DemoInstanceConfig). On save, mcm-nexus/backend does a lightweight credential and path check against the registry before persisting. MCM-09's GET /api/mcm-app/downloads/package and MCM-10's GET /api/mcm-app/upgrade/latest//package now read this stored config to authenticate to the real registry — a raw-artifact fetch (the same curl -u <user>:<password> <raw-repo-url>/... pattern mcm-devops's CI already uses against its NEXUS_RAW_URL artefacts) for the installer tarball, and the equivalent image-pull path for upgrade bundles — instead of assuming some unspecified pre-existing internal credential, closing the gap those two stories previously left open. A new POST /api/admin/registry/fetch-versions endpoint, triggered only by the Nexus Admin clicking "Fetch Versions," lists every version found under the configured Repository Path and upserts any not already known into MCM-33's Release table as PENDING — there is no scheduled job; the catalog is only ever refreshed on demand.

---

UI / Frontend Changes

• New (admin)/settings/registry page: Registry URL field, Repository Path field, registry admin username field, registry admin password field (masked, write-only after save).
• Validate-on-save behavior with a clear inline error if the registry rejects the credentials or the path doesn't resolve.
• "Fetch Versions" action on the same page: triggers the fetch, then shows a short result summary (e.g. "3 new versions found") with a link straight to MCM-33's Releases page to review and approve them.
• Nexus Admin console shows a "Registry not configured" banner/blocked-state on the download/upgrade areas until this settings page has a saved, valid connection.
• No change to the customer-facing UI in MCM-09/MCM-10 — this story is purely a Nexus-Admin-side prerequisite; customers still only ever see their own MCM App credentials.

---

Out of Scope

• Supporting more than one Artifact Registry or Repository Path — a single configured connection serves all install/upgrade traffic.
• Credential rotation with an old+new grace period — rotation is immediate.
• Automatic/scheduled discovery of new versions — discovery only ever happens when the Nexus Admin explicitly runs "Fetch Versions."