Release Automation

Expand all | Collapse all

Is there any cleanup policy for artifacts uploaded to inbuilt Nexus repository?

Jump to Best Answer
  • 1.  Is there any cleanup policy for artifacts uploaded to inbuilt Nexus repository?

    Posted 12-13-2018 07:28 PM

    By default do any artifacts that get uploaded to the artifact Nexus repository which is inbuilt to Nolio get cleaned up at any time? If so is the policy of cleanup configurable?


    This is referring to artifact versions which are configured with the "Store artifact in local repository" option set to true.


    The instance of Nolio that we run is experiencing issues with a lack of disk space and the inbuilt Nexus repository for artifacts is consuming a significant percentage of the disk, therefore we would like to try and clean up some of these artifacts. What would be the recommended method of cleaning up the artifacts which have been uploaded to the inbuilt artifact Nexus repository, deleting the files directly on the disk, or using Nexus itself to delete the artifacts? If we were to create scheduled tasks in this Nexus which removed artifacts which were uploaded by Nolio would this be something that is not advised?

  • 2.  Re: Is there any cleanup policy for artifacts uploaded to inbuilt Nexus repository?
    Best Answer

    Broadcom Employee
    Posted 12-14-2018 12:17 PM

    Hi Luke,


    Long time no talk. I hope all is well and your holidays are happy. Regarding this request for information, can you have a look at the doc here: How to purge Release Automation artifacts via Sonatype Nexus? 


    I'm 99.9999% certain that CA Release Automation will not periodically delete any of your artifacts. And there is no policy that I'm aware of. The doc walks through removing the artifacts through the Nexus UI which I believe would be considered best practice since:
    a. Deleting the artifacts in RA UI doesn't remove the artifacts from nexus. 

    b. Deleting the files from disk would leave orphaned indexes in Nexus. If this happens I'm not sure how Nexus handles this (performance or cleanup wise). 


    The only issue with removing the files from Nexus is that jobs might fail if:

    a. the original source of the artifacts are not available;

    b. the artifact is not in nexus anymore.


    Some time ago (probably before storing artifacts in local repo option was made available) a best practice was shared with me by a product manager that using an external artifact repository was preferred over use of the local nexus repo used by the management server since:

    a. using an external repo would be sure to not use resources (cpu, mem, disk io, network, etc..) on the management server during jobs in an active environment. 

    b. the internal nexus repository is not an enterprise install of an artifact repository. it was installed and used, from the beginning, to meet the needs of the management server and the management of the library files used by it and throughout the environment (like actionpacks, etc..) specific to the product. 


    I'm not trying to completely steer you away from changing how you use Nexus. I'm just sharing everything I know on the matter. Do let us know if you have any other problems and/or questions.




  • 3.  Re: Is there any cleanup policy for artifacts uploaded to inbuilt Nexus repository?

    Posted 12-14-2018 05:13 PM

    Hi Gregg,


    I'm doing well and the holidays have been good so far.


    Thanks, that document on purging artifacts is useful. That fits in with how I was planning on approaching the problem. I think the main concern was whether deployments would fail if the artifact was removed from the inbuilt Nexus repository, but (providing the original source is still available as you point out) then the artifact will get downloaded again on next deployment.


    We might investigate a standalone repository at some point in the near future. However, as long as we can manage and purge artifacts to clear up some space without impacting deployments then that's enough to prevent us running out of space.