Skip to content

Migrate from Sonatype Nexus Repository

View as Markdown

This page moves the files in your Nexus Repository 3 repositories to CloudRepo and repoints your builds, with Nexus left running until your builds pass against CloudRepo. It copies files and nothing else: your users, permissions and every other piece of data that is not a file stay in Nexus.

  1. List what you have and decide where each repository goes.
  2. Create the repositories in CloudRepo.
  3. Export the files from Nexus.
  4. Import them into CloudRepo.
  5. Repoint your builds.
  6. Check, then cut over.

You need a CloudRepo organization. If you have none, sign up.

List your repositories from Nexus with its REST API, which lists the repositories the authenticated user has the browse permission to access. Give curl the credential of a Nexus user that can read them through a netrc file, as in step 3.

Terminal
curl --netrc-file ~/.nexus.netrc --silent --fail \
"https://nexus.example.com/service/rest/v1/repositories" | jq -r '.[] | [.name, .format, .type] | @tsv'

Then decide where each one goes. The left column uses the format and type names that Sonatype’s repositories API returns:

In Nexus In CloudRepo
Hosted repository, format maven2, npm, pypi or docker A repository of that format. Its files are what you export and import.
Proxy repository A proxy repository, if the upstream is one CloudRepo offers. Nothing to export: a proxy fills itself from the upstream.
Group repository No copy. Sonatype describes a repository group as the aggregated content of multiple proxy and hosted repositories under one URL, so you move those. Point builds at the CloudRepo repositories directly. For Maven and Docker, a group repository can serve several repositories under one address.
Any other format No CloudRepo repository for it. CloudRepo hosts Maven, Python, npm and Docker.

This page covers Nexus Repository 3, whose REST API the commands use. For another Nexus version, export the files by any means that keeps each repository’s directory layout, then continue at step 4.

For each hosted repository, create a repository of the same format in CloudRepo, and give it the name your builds already use if you can, so a URL changes in one place only. See Creating a repository. Then add whoever needs access: add users, and create a repository token with Read + write for the import and Read only tokens for builds that only pull. Nexus roles do not copy: you choose each CloudRepo user’s access when you add them.

Give your Nexus credential to curl through a netrc file, so it is on no command line.

~/.nexus.netrc
machine nexus.example.com
login nexus-user
password NEXUS_PASSWORD

Keep the file readable by you alone (chmod 600 ~/.nexus.netrc). Then, for each hosted repository, page through its assets with the assets API and download each one into a directory named for the repository. Sonatype’s pagination page says a response carries a continuationToken while more items are available, that you pass it back as continuationToken= on the same query for the next page, and that a null token marks the last page:

Terminal
HOST=https://nexus.example.com
REPO=maven-releases
NEXT=""
: > "$REPO.txt"
while :; do
page=$(curl --netrc-file ~/.nexus.netrc --silent --fail --get --data-urlencode "repository=$REPO" \
${NEXT:+--data-urlencode "continuationToken=$NEXT"} "$HOST/service/rest/v1/assets")
printf '%s' "$page" | jq -r '.items[] | [.path, .downloadUrl] | @tsv' >> "$REPO.txt"
NEXT=$(printf '%s' "$page" | jq -r '.continuationToken // empty')
[ -n "$NEXT" ] || break
done
while IFS=$'\t' read -r path url; do
curl --netrc-file ~/.nexus.netrc --silent --fail --create-dirs --output "export/$REPO/$path" "$url"
done < "$REPO.txt"

Expected: export/<repository>/ holds every asset the assets API listed, saved at the path it gives that asset. For a Maven repository that is the Maven layout CloudRepo takes as it is. The import loops look under ./export for npm tarballs (.tgz), Python wheels (.whl) and source distributions (.tar.gz), wherever they sit.

This page does not export Docker images. Write the images you want to keep, as name:tag lines, into images.txt from whatever list you already hold, and the import copies each image with the Docker CLI.

Import artifacts into CloudRepo has one loop for each format. Run it for each repository, then check the bytes arrived. You can run a loop again after a failure, and what a second run skips and what it replaces depends on the format: see Running a loop again.

In each build, replace the Nexus URL and credential with the CloudRepo repository’s URL and a repository token. The page for your build tool shows the file to change:

Pull Maven artifacts and Publish Maven artifacts: ~/.m2/settings.xml holds the credential, and pom.xml holds the repository URL.

The username for every client except npm is the email address of the account that created the token, and the password is the token. In CI, store the token in the CI system’s secret store and expose it as an environment variable, as the pages above show; do not write it into a script or a committed file.

Do this in order, and leave Nexus running until the last step:

  1. Build against CloudRepo, with Nexus still up. Point one project at CloudRepo and run its full build, then the projects that depend on it. A 401, 403 or 404 has the same causes as when you publish by hand: see “When a Client Answers 401, 403 or 404” on Repository tokens.
  2. Publish one new version to CloudRepo from CI and install it from a second machine.
  3. Switch every build that still names Nexus, and every CI job’s secret, to CloudRepo.
  4. Stop publishing to Nexus. From now on a new version exists in CloudRepo only.
  5. Keep an export of Nexus until you are sure nothing reads it. Step 3 of this page is that export.

Webhooks, if you used any, are not copied. CloudRepo’s are in Webhooks.

If you are stuck, email support@cloudrepo.io with your organization name, the repositories involved, the command you ran and the error it printed.