Hi, understand that Content Replication for nexus only works for proxy repository (destination) from hosted repository (source), whereby the metadata are not replicated.
For my current use case, i would like to implement daily-cleanup for my hosted repository, which affects users pointing to the proxy repository after the cleanup is executed. (i.e nuget search command not able to work). Is there a way for me to execute the cleanup at the hosted side, and also still have the ability to build my source code, when i point to the proxy repository? Or is there like a replication feature that replicates metadata over to the other repository also, (i.e hosted to hosted), such that i can perform cleanup after replication is done.
Context: the 2 repository exist in two segregated environment, and my job is find a way to bring over the files in hosted repository (source) such that developers can point to the proxy repository (destination) to build their source code. Right now, it seems that i would need to store all the files in my source even after replication, which I do not want, because i do not want to keep the files in my source repository.
You’re quite right, content replication wasn’t intended as a way to permanently relocate components, it still assumes the source hosted repository is the “repository of record”.
i would like to implement daily-cleanup for my hosted repository, which affects users pointing to the proxy repository after the cleanup is executed.
This doesn’t sound quite right. The proxy repository should permanently cache anything that’s been requested (unless the proxy itself is cleaned up). If you have content replication active, any newly published components should be (Please note that older components added before replication was turned on aren’t replicated currently.)
Is there some reason you’re building components and publishing them to a temporary location first, before putting them in the final location? Do you have some kind of approval workflow?
It appears that the admin in-charged of publishing files like .nupkg for nuget is only able to push into the source nexus repository (nuget hosted), and does not have access to the destination nexus repository (nuget-proxy), which is why we have adopted the replication feature, for files to flow towards the destination whereby teams that actually have access to the destination repository can use it to build their nuget resources. Note that we are operating in an air-gapped environment, which is why the admin’s job is to bring in nuget nupkg dependencies for the other team to build their own project.
The destination repository is tightly controlled, if not for the restriction for the admin, he/she could have push straight into the destination nexus repository (nuget-hosted).
To add on, our hosted repository (nuget hosted) that the admin pushes the nupkg files into is like an adhoc/temp repository that does not have persistent volume/data, which is also why we have added in the cleanup policy to the source repository. This cleanup breaks nuget install/restore operation on the destination repository where the other team references the nuget-proxy.
I am not sure how to proceed with this, it seems that we would need to either store the data on the hosted repository side for the whole process to work (remove cleanup policy), or just to get approval for the admin to push directly to the destination repository, but that seems highly unlikely to happen. Any idea/feedback would help. Thankyou.
I’m still not quite clear why the cleanup policy is causing problems. Are the settings too aggressive, so cleanup is taking place before replication can move the content? A NuGet proxy repository should continue to serve locally cached files even if the upstream content is missing, as long as that content was moved over in the first place. Sonatype support should be able to help diagnose and correct this.
In either case, another option would be to use an import/export-based workflow, exporting from a hosted repository and importing into another hosted repository. That’s another approach for moving content into air-gapped environments.