What do the scheduled tasks in Nexus do, and how often should I run them?

It isn't possible to come up with a set of scheduled tasks that is correct for everyone.  How often you will need to run the various tasks is heavily dependent on how constrained your disk space is, how much traffic your Nexus instance receives, and what sort of policies your organization has in place for retaining binary artifacts.   That said, see below for information about what the various tasks do, and general recommendations for how often you should run them.

Indexing Tasks

Consult our dedicated article discussing indexing tasks.

General Maintenance Tasks

These tasks are used to control how much disk space Nexus consumes, to optimize performance, and to back up critical files.

  • Backup all Nexus Configuration Files (pro only) - This Nexus Professional plugin creates archives of the Nexus configuration data, so that you can recover if you make a mistake while administering Nexus.
  • Empty Trash - Most filed deleted in Nexus (either automatically or from the UI) are moved to a trash directory.  Run this task periodically to recover disk space.
  • Evict Unused Proxied Items from Repository Caches - This task removes files from proxy repositories that have not been accessed in the specified number of days. This is useful for controlling disk space, particularly in snapshot proxy repositories.
  • Purge Nexus Timeline - The Nexus "timeline" is the system feed.  Schedule this task to remove old events from the feed so that disk usage doesn't get too large.
  • Remove Snapshots from Repository - Remove old snapshots from hosted repositories. Usually keeping the last couple of snapshots is all that is needed, and checking "remove if released" is also a good idea.
  • Remove Unused Snapshots From Repository - Remove snapshots which haven't been downloaded in the specified number of days.  Useful for cleaning up old snapshots which do not have a corresponding release GAV.   Deleted snapshots are moved to the trash directory so they can be recovered if necessary.
  • Remove Releases From Repository - Prunes old releases out of repositories (use this with caution)
  • Purge Orphaned API Keys (pro) - Used to remove old user tokens and NuGet API keys which are no longer associated with a Nexus user.  User tokens and API keys become orphaned after a user or administrator resets them.
  • Drop Inactive Staging Repositories - Remove staging repositories which have not seen any activity (open/close/promote) in the specified number of days.  Useful for clearing out forgotten staging repositories.

Recommendation:

Back up configuration files daily.  Empty trash and purge snapshots daily (the exact number of days to keep and number of snapshots is up to you).

Purge the timeline weekly, keeping 30 days of records is usually sufficient, but this is up to you.

Schedule the "evict unused proxied items" task if you need to reclaim space.  This can run weekly, and if something hasn't been accessed for 120 days it is a good candidate to be cleared.

Purge Orphaned API Keys - If you are using either the User Token or NuGet features then run this task weekly.

You should schedule a snapshot remover.  How often you should run it and how long it keeps snapshots will vary depending on your build setup.  If you're unsure, a good starting point is:

  • Repositories: All Repositories
  • Snapshot retention (days): 30
  • Minimum snapshot count: 3
  • Remove if released: yes
  • Grace period after release (days): 7
  • Delete immediately: yes

The above is conservative, if disk space is an issue the minimum snapshot count and snapshot retention days can be reduced. Also note that not all of the above options are available on older versions of Nexus.

 

NuGet Tasks

* Download NuGet Feed - Check the remote RSS feed for NuGet proxy repositories for updates
* Rebuild NuGet Feed - Rebuild the entire NuGet RSS feed for a NuGet repository.

Recommendation:

If you have NuGet proxy repositories run a "Download NuGet Feed" task daily

P2 (Eclipse Update Site) Tasks

  • Mirror Eclipse Update Site - If you have proxies of old style (pre Ecilpse 3.4) update sites you will need to schedule this task. Note that these proxy repositories have a provider type of "P2 Update Site", not "P2".

Recommendation:

If you have "p2 update site" proxy repositories run this once a day.  This task is not needed for new style "p2" proxy repositories.

Repair Tasks


These tasks do not need to be run regularly, they are intended to be used to recover from situations where direct manipulation of repository storage on disk has occurred (not through Nexus)

  • Expire Repository Caches - Poxy repositories cache information about what is available on their remotes in order to improve performance.  This task clears these caches.
  • Rebuild Maven Metadata Files - Rebuilds maven-metadata.xml tasks from information on disk.  This should only be run if you have a workflow that involves direct manipulation of maven repository storage on disk.
  • Yum: Generate Metadata - Used to regenerate yum metadata.  Again, this should not be needed during regular operation, but if you have recently enabled yum metadata creation on a hosted repository you will need to schedule this to populate the metadata.

Recommendation:

In general you do not need to schedule these tasks to run regularly.



Have more questions? Submit a request

10 Comments

  • 0
    Avatar
    wognin a

    Thanks for these explanations very usefull.

    Anyway I have one concern :

    - I use Nexus Pro 2.11.4-01, and I have some proxy repositories that I would like to clean periodicly.
    - I've use Scheduled Task with "Remove Releases From Repository" type for All(Maven2) but it tells me that : "Skipping 'myrepositoryId' because it is a proxy repository".
    - So the task fails.

    How can I delete automatically artifacts in proxy repository ?

    Thanks for your help.

    Wognin

  • 0
    Avatar
    Rich Seddon

    Use the "evict unused proxied items from repository" task to clean up old artifacts from proxy repositories.

  • 0
    Avatar
    Jason Tran

    I schedule a task to remove old artifacts in Snapshots repository, the job is executed with no error, but artifacts are not removed.

    Reading from this post: https://issues.sonatype.org/browse/NEXUS-4132

    Look like my  VERSION_FILE_PATTERN is not correct, it is missing '-BBB'. How do include that in the file pattern?

    This is how I manually upload artifact to Nexus Snapshot repo:

    mvn deploy:deploy-file -DgroupId=Auction -DartifactId=RetailEnterprise-ReleaseNotes -Dversion=$VERSION-SNAPSHOT -Dpackaging=tar.gz -DrepositoryId=snapshots -Durl=http://nexus1.channel-corp.com/nexus/content/repositories/snapshots -Dfile=ReleaseNotes-$VERSION.tar.gz

    This is how files look like on Snapshots repo:

    This is scheduled task setup:

  • 0
    Avatar
    Rich Seddon

    There's nothing wrong with your snapshot, that's a standard maven timestamped snapshot.  There's nothing wrong with the snapshot remover either, you've told it to leave 30 unique timestamped snapshots in each version folder.  The folder you're showing has only 1, so nothing is removed.

  • 0
    Avatar
    Jason Tran

    Maybe I misunderstanding something. Currently I have more than 30 build artifacts (SNAPSHOT), for example: 2.18.100-SNAPSHOT, 2.18.101-SNAPSHOT and so on. I want remove those and only keep last 30.

     



  • 0
    Avatar
    Rich Seddon

    The task removes timestamped versions within a version folder.  It operates within each of the folders you've listed.  So it will remove with "Auction/RetailEnterprise/2.18.0-SNAPSHOT", for example.  It doesn't remove entire version folders.

    It looks like your build is incrementing the version number (2.19.<number>-SNAPSHOT) every time it's run? That's not how snapshots are intended to be used, you should leave the SNAPSHOT version the same, and let Maven create the build numbers.    

  • 0
    Avatar
    Jason Tran

    Ah... ic

    So this is command we are using:

    mvn deploy:deploy-file -DgroupId=Auction -DartifactId=RetailEnterprise-ReleaseNotes -Dversion=$VERSION-SNAPSHOT -Dpackaging=tar.gz -DrepositoryId=snapshots -Durl=http://nexus1.channel-corp.com/nexus/content/repositories/snapshots -Dfile=ReleaseNotes-$VERSION.tar.gz

    We should keep the same directory like: 2.18-SNAPSHOT?

    mvn deploy:deploy-file -DgroupId=Auction -DartifactId=RetailEnterprise-ReleaseNotes -Dversion=2.18-SNAPSHOT -Dpackaging=tar.gz -DrepositoryId=snapshots -Durl=http://nexus1.channel-corp.com/nexus/content/repositories/snapshots -Dfile=ReleaseNotes-$VERSION.tar.gz
  • 0
    Avatar
    Rich Seddon

    Yes, if you do that Maven will automatically generate a new timestamped version for each snapshot deployed.  And the snapshot remover in Nexus will work with these.

  • 0
    Avatar
    Jason Tran

    Thank you!

  • 0
    Avatar
    Peter Lynch

    We are closing this article for comments.

    If you have a support license, please contact us by submitting a support ticket.

    If you do not have a support license, please use our Nexus Users List or our other free support resources.

Article is closed for comments.
Powered by Zendesk