Skip to main content

CPP Artifactory

This is not the CNP Artifactory. CPP runs its own Artifactory, on its own hosts, with its own repositories and its own access. Nothing published to one appears in the other. For the Cloud Native Platform’s instance see CNP Artifactory.

CPP Artifactory is the platform’s artefact repository. Every CPP Maven artefact (service WARs, library JARs, Liquibase migrations, Azure Function packages) is published there, and almost everything CPP builds or deploys reads from it: Maven builds, npm builds, Dockerfile ADD lines, Terraform function-app deployments, and the yum repositories on CPP virtual machines.

This is the main difference from CNP. CNP’s Artifactory is primarily a pull-through cache of public repositories, and its own artefacts are published elsewhere. CPP Artifactory is where CPP’s own build outputs live. It also proxies upstream registries, but that is the secondary job.

Instances and addresses

There are two instances, one per platform side, and each answers on two names.

Instance Web UI / external Build agents / internal
Non-live (MDV) https://libraries.mdv.cpp.nonlive/artifactory https://libraries-internal.mdv.cpp.nonlive/artifactory
Live (MPD) https://libraries.mpd.cp.cjs.hmcts.net/artifactory https://libraries-internal.mpd.cp.cjs.hmcts.net/artifactory

The two names are not old and new. libraries.* is the browsing and general-serving path and reaches the host through a proxy pair; libraries-internal.* resolves to the host directly and is the name that pipelines, Dockerfiles and settings.xml use. Use libraries-internal.* in anything automated, and libraries.* when you want the UI.

Both are on the Crime network. You need the CPP VPN to reach either; neither is on the internet. See onboarding for VPN access.

Non-live is where publishing happens. No CPP pipeline deploys artefacts to the live instance. Live gets them by pulling from non-live: see Publishing and promoting artefacts.

Repositories

Every repository link on these pages points at an internal HMCTS repository. If a link returns a 404, you are probably not a member of the owning team rather than looking at a broken link; ask CPP DevOps for access.

Repositories are provisioned as JSON definitions through the Artifactory API by the artifactory Ansible role in crime-idam-ansible. The full per-instance list is in sp-ansible/group_vars/10_platform_nlv/artifactory.yml and its 10_platform_lv equivalent (about seventy repositories on non-live). These are the ones you will meet.

Read from these

Repository Type What it is
repocentral Maven virtual The endpoint you resolve from. Aggregates the CPP local repositories and the upstream Maven proxies behind one URL.
api/npm/npm-virtual npm virtual The npm registry. Aggregates npm-release-local and the npmjs mirror. Non-live only.
pypi-virtual, gems-virtual virtual Python and Ruby equivalents, used by platform tooling rather than services.

Publish to these

Repository Type Written by
libs-snapshot-sp-azure Maven local Context-service builds on main, before the release step runs
libs-release-sp-azure Maven local Context-service releases on main (the jgitflow release step deploys the finished, non-snapshot version here), and library builds on a configured release branch
team-libs-snapshot-sp-azure Maven local Context-service and library builds on team, feature and other non-release branches
libs-snapshot-local, libs-release-local Maven local Older and non-context pipelines, including the Rota application
npm-release-local npm local UI library publishes, via npm-virtual

Context services deploy to libs-snapshot-sp-azure and then, later in the same pipeline run, to libs-release-sp-azure: see Publishing and promoting artefacts for why there are two deploys.

Upstream proxies and generic stores

maven2, jcenter, npmjsmirror, pypi.python.org, rubygems.org, remote.centos.repo, azure-cli, hashicorp-remote, remote.jboss.repo, alfresco and around forty more are remote repositories that cache a third-party registry. Generic repositories hold files that are not packages: helmsman-binaries (the Helmsman and helm-diff zips the deployment pipelines download), ftp.mozilla.org-generic (the pinned Firefox ESR used by UI end-to-end tests), chromedriver, github-generic.

Because repocentral includes the upstream proxies, a CPP build that resolves from repocentral gets both CPP artefacts and third-party dependencies from one URL, and never talks to Maven Central directly.

How non-live and live relate

On non-live, libs-release-sp-azure and team-libs-snapshot-sp-azure are local repositories: real storage that builds deploy into.

On live, repositories with the same names are remote repositories pointing back at the non-live instance, restricted to uk/gov/moj/cpp/**/* and caching what they fetch. The live host trusts the non-live CA and has a hosts entry for it, both set up by the Ansible role.

So an artefact reaches live by being requested there, not by being pushed there. Two consequences matter day to day:

  • Live resolves releases only. Live’s repocentral aggregates libs-release-sp-azure, libs-release-local, libs-release-ukcloud, rota-libs-release-local, alfresco, maven2, bintray-cjscommonplatform and ext-release-ukcloud. No snapshot repository is in it. A -SNAPSHOT version cannot be deployed to live.
  • A newly published artefact can 404 on live for a while. On live, libs-release-sp-azure and team-libs-snapshot-sp-azure cache a failed lookup for 1800 seconds and repository metadata for 600. If a release that definitely exists on non-live is missing on live, that is usually this, not a fault.

Both are cleared the same way: Zap Caches, described below.

Access

What How
Browsing and downloading CPP VPN, then the libraries.* UI
Build credentials Already in the Azure DevOps secure files settings.xml and settings-security.xml; you do not handle them
Admin login HashiCorp Vault; ask CPP DevOps for the path
A new named account or a new repository Raise a ticket with Technical Services

Teams do not get individual logins as a matter of course. Most work needs none: resolving is anonymous and publishing is done by the pipeline.

Common problems

Symptom What it usually is
502 Bad Gateway during a build The proxy in front of Artifactory, not Artifactory. Re-run the job. If it persists, raise it with Platform Operations with the timestamp.
Live has an old copy of an artefact A stale cache in the live remote repository. Compare Last Modified on both instances; if they differ, Zap Caches on live (below).
A release is on non-live but 404s on live The 1800-second missed-retrieval cache. Wait it out or Zap Caches.
A -SNAPSHOT version will not resolve on live Working as configured. Live carries no snapshot repositories. Release it.
TLS errors against *.cpp.nonlive Trust the CA rather than disabling verification. Pipelines get it from the cpp-nonlive-ca.pem secure file; see CI/CD integration.
HTTP 500s across the board Often the filestore filling up. This is an incident, not a build problem: see the recovery runbook.

Zap Caches

To clear a stale or negatively-cached entry on live:

  1. Sign in to the live UI as admin (password from HashiCorp Vault).
  2. Artifacts → select the affected repository or folder in the tree.
  3. Right-click, or use the Actions menu → Zap Caches, and confirm.
  4. Request the artefact again and re-check Last Modified.

This only expires cached entries; the next request re-fetches from non-live. It cannot create an artefact that was never published.

How this differs from CNP Artifactory

CPP CNP
Edition JFrog Artifactory Pro JFrog Artifactory OSS
Hosting Azure VMs, configured by Ansible AKS (PTL / PTL-Sandbox), managed by Flux
Primary purpose Stores CPP’s own artefacts Caches upstream dependencies
Published to by Azure DevOps pipelines, via Maven and npm Rarely written to; CNP Java libraries go to Azure Artifacts instead
Instances Non-live and live, live pulling through from non-live Production and Sandbox, independent
Backup Azure Backup of the VM, 30 days None on the PVC
Managed by CPP DevOps / Platform Operations Platform Operations
This page was last reviewed on 22 September 2026. It needs to be reviewed again on 22 March 2027 by the page owner platops-build-notices .