For Nexus 2, we’ve implemented some complex release promotion, based on building more or less independant components that are tested and released in combination in an integration pipeline. On release promotion, the related artifacts are copied from CD Nexus repository to a particular Releases repository. This is done by a Spring Boot Java service (running directly on the Nexus server) that just copies the files, and is exposed to Jenkins via an own REST API.
Now we’re planning migration to Nexus 3 and have to find a way to implement the release promotion. I currently believe that existing features in Nexus Pro (Tagging, Staging) do not fully satisfy our needs, so we probably need to implement release copying ourselves.
As far as I understood, the artifact files (assets) are still plain files inside of the Blob stores, organized in folders, but the meta data is stored in databases. Would it be possible to just copy the artifact files to another Nexus repo and somehow rebuild the metadata based on blob storage (using some of the repair tasks)? Or is such approach strongly discouraged?
Alternatively, which approach would be best fit for our needs:
- using Nexus REST API,
- upload and run a custom script,
- or rather develop a custom plugin?
Thanks for any hints…!
You can’t directly manipulate blob storage in Nexus Repo 3.
It sounds like the tagging/staging features in Nexus Repo Pro might work better for this use case? This would allow you to move tagged into a new repository.
Rich, thanks for your answer. We already looked at the staging feature, but can’t use it. We’d rather need a “copy” to staging repo instead of a “move”. This is because a component C in version 123 might be part of different releases of the product P, a new version of C is only built when there are changes to C’s sources. Thus, for release promotion, C’s artifacts have to be copied to staging repo, but still must be available in unstable/test repos.
Hence, since we can’t manipulate blob storage, which approach would you recommend instead?
Ideally, the staging feature would be extended before long to optionally copy instead of move the tagged components
Christopher - With the REST API you can download components and upload them to another repository. This would be like a copy.
First, use the Component REST API Components API to get details of the component, including the assets which are the actual things you will download. As part of the details you can also collect information about the Asset/component like the GAV. Then using the same REST API you can upload the component providing all the details you collected in the details.
Thanks for your reply. This is exactly what we had in mind regarding the approach “using Nexus REST API”.
However, we’re talking about 750 JARs that need to be downloaded to the client and then uploaded back to Nexus server just because there is no “copy”. I was afraid that this maybe causes some performance penalties? Using a script that does this directly on Sonar server is perhaps much faster…?