Configuring and Executing Tasks
The repository manager allows you to schedule the execution of maintenance tasks. The tasks can carry out regular maintenance steps that will be applied to all repositories or to specific repositories on a configurable schedule or simply perform other system maintenance. Use the Tasks menu item in the System section of the Administration menu to access the feature view, shown in Figure: “Managing Tasks”, to manage your tasks.
User accounts with the nx-admin or nx-tasks privileges can access this menu item.
Figure: Managing Tasks
The list interface allows you to add new tasks with the Create task button as well as inspect and work with the configured tasks. The list shows the following columns:
A user-defined name for the task to identify it in the user interface and log files.
The type of action the scheduled task executes. The list of available task types is documented in more detail below.
Tasks can either be Waiting for their next run, currently Running or Disabled.
The Schedule column shows the Task frequency e.g., Daily, Monthly, Manual, and others.
This column displays date and time of the next execution of the task based on the configured schedule.
Last run and Last result
These columns display the date and time as well as the result and duration of the last execution of the specific task.
When creating or updating a scheduled task, you can configure the following additional properties:
Enable or disable a specific task with the checkbox.
Configure a notification email for the task execution. If a scheduled task meets the notification condition configured below, a notification email will be sent to the configured email recipient. In the case of a failure, the notification will contain the task identifier and name as well as the stack trace of the failure. Otherwise, a summary of the task execution, including the start time and duration, will be sent.
Notification Condition NEW IN 3.22
Notifications can be sent on Failure or on Success or Failure. If Failure is selected, a notification email will be sent only if the task ends abnormally.
Selecting the task frequency allows you to configure the schedule for the task executions. Available choices are Manual, Once, Hourly, Daily, Weekly, Monthly, and Advanced (provide a CRON expression). Apart from Manual, all choices trigger display of a custom user interface for scheduling the specific recurrence. Weekly scheduling requires at least one day of the week to be selected. The advanced setting allows you to provide a CRON expression to configure more complex schedules.
The syntax used for Advanced (provide a CRON expression) follows the UNIX-style CRON syntax. CRON expressions are comprised of 6 required fields and one optional field separated by white space as described in Table 4.1, “Fields of a CRON Expression from Left to Right” and the following paragraphs. A simple expression example is
0 0 9 * * ?. This configuration triggers a task execution every day at 9:00 in the morning. Further examples are available in Table 4.2, “CRON Expression Examples”.
Allowed Special Characters
|Month||1-12 or JAN-DEC|
|Day-of-Week||1-7 or SUN-SAT|
|Year (Optional)||empty, 1970-2099|
Table 4.1. Fields of a CRON Expression from Left to Right
This character is used to specify any value. For example, * in the minute field means every minute.
This character is allowed for the day-of-month and day-of-week fields. It is used to specify no specific value. This is useful when you need to specify something in one of the two fields, but not the other.
This character is used to specify ranges. For example 10-12 in the hour field means "the hours 10,11 and 12".
This character is used to specify additional values. For example MON,WED,FRI in the day-of-week field means "the days Monday, Wednesday, and Friday".
This character is used to specify a start value and increments. For example "0/15" in the seconds field means "the seconds 0, 15, 30, and 45". And "5/15" in the seconds field means "the seconds 5, 20, 35, and 50". Specifying * before the / is equivalent to specifying 0 as the value to start with. Essentially, for each field in the expression, there is a set of numbers that can be turned on or off. For seconds and minutes, the numbers range from 0 to 59. For hours 0 to 23, for days of the month 0 to 31, and for months 1 to 12. The / character simply helps you turn on every "nth" value in the given set. Thus "7/6" in the month field only turns on month "7", it does not mean every 6th month, please note that subtlety.
This character is allowed for the day-of-month and day-of-week fields. This character is short-hand for "last", but it has different meaning in each of the two fields. For example, the value L in the day-of-month field means "the last day of the month" - day 31 for January, day 28 for February on non-leap years. If used in the day-of-week field by itself, it simply means 7 or SAT. But if used in the day-of-week field after another value, it means "the last xxx day of the month" - for example 6L means "the last Friday of the month". When using the L option, it is important not to specify lists, or ranges of values, as you will get confusing results.
This character is allowed for the day-of-month field. This character is used to specify the weekday (Monday-Friday) nearest the given day. As an example, if you were to specify "15W" as the value for the day-of-month field, the meaning is: "the nearest weekday to the 15th of the month". So if the 15th is a Saturday, the trigger will fire on Friday the 14th. If the 15th is a Sunday, the trigger will fire on Monday the 16th. If the 15th is a Tuesday, then it will fire on Tuesday the 15th. However if you specify 1W as the value for day-of-month, and the 1st is a Saturday, the trigger will fire on Monday the 3rd, as it will not jump over the boundary of a months days. The W character can only be specified when the day-of-month is a single day, not a range or list of days.
W characters can also be combined for the day-of-month expression to yield
LW, which translates to "last weekday of the month".
This character is allowed for the day-of-week field. This character is used to specify "the nth" XXX day of the month. For example, the value of "6#3" in the day-of-week field means the third Friday of the month (day 6 = Friday and #3 is the 3rd one in the month). Other examples: 2#1 is the first Monday of the month and 4#5 is the fifth Wednesday of the month. Note that if you specify #5 and there is not 5 of the given day-of-week in the month, then no firing will occur that month.
The legal characters and the names of months and days of the week are not case sensitive.
|Fire at 12pm (noon) every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day during the year 2015|
|Fire every minute starting at 2pm and ending at 2:59pm, every day|
|Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day|
|Fire every 5 minutes starting at 2pm and ending at 2:55pm, AND fire every 5 minutes starting at 6pm and ending at 6:55pm, every day|
|Fire every minute starting at 2pm and ending at 2:05pm, every day|
|Fire at 2:10pm and at 2:44pm every Wednesday in the month of March.|
|Fire at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday|
|Fire at 10:15am on the 15th day of every month|
|Fire at 10:15am on the last day of every month|
|Fire at 10:15am on the last Friday of every month|
Fire at 10:15am on every last Friday of every month during the years 2002, 2003, 2004 and 2005
|Fire at 10:15am on the third Friday of every month|
Table 4.2. CRON Expression Examples
The Start date and Start time allow you to configure a specific date and time from when the schedule should be activated. The Time to run this task settings is used to configure the actual time of the task execution.
Task-type specific configuration is displayed below the notification email input field and differs for each scheduled task.
Types of Tasks and When to Use Them
Tasks with the prefix "Repair -" are only intended to be run if you are having specific trouble with your system. These tasks should only be run manually, not scheduled, and should usually only be run at the advice of a Sonatype staff member.
The following tasks are available:
|Task Name||Task Id||Description||Typically Scheduled|
Admin - Cleanup Tags
This task will allow you to cleanup tags once they reach a certain age, haven't been modified in a certain period, or using a regular expression on the name.
You can also choose to delete the components along with those tags, as well as restrict this component deletion to a particular format or repository.
See additional details on the tagging page.
Admin - Compact blob store
Content deleted from a blob store is not physically deleted from the storage device. Instead it is only internally marked for deletion. This task performs the actual deletion of the relevant files, and therefore frees up the storage space.
This only affects blob store of type File. S3 type blob stores are cleaned up using AWS Lifecycle.
Admin - Change repository blob store
|repository.move||This task can be used to change a repository blob store. See Change repository blob store for more details.||No|
Admin - Delete orphaned API keys
This task deletes old, unused API keys. These keys are generated, for example, when using the User Token feature and become orphaned when the associated user account is deleted.
Admin - Export databases for backup
This task performs a full backup of the underlying config, security and component databases - not blobstore content. You must choose a location for the backup data for this task. When you run the backup, the task adds a timestamp to the backup files that are created in the backup data location. It is important to note this task does not backup actual repository content.
Admin - Execute script
|script||Scripts can be provided in the Source field and have to be written using the Groovy programming language. These scripts can use the APIs of the repository manager to perform maintenance and other modification tasks. Please consult related documentation for writing scripts and additional information/references to the Javadoc and source.||Optional|
Admin - Log database table record counts
This task logs clustered database record counts for each node. The task is automatically added when clustering is enabled and can be disabled by including an additional property in the nexus.properties file:
Admin - Remove a member from a blob store group
|blobstore.group.memberRemoval||This task removes a blob store from a group. Each blob within the removed store is written back to the group and then deleted from the removed blob store.||No|
Docker - Delete incomplete uploads
This task cleans up orphaned files that may exist in temporary storage as result of a restart or incomplete/interrupted uploads.
The Age in hours parameter allows you to configure the minimum age of incomplete uploads to be deleted.
Docker - Delete unused manifests and images
|repository.docker.gc||This task will handle deletion of content that is no longer referenced, images that are no longer referenced by a tagged manifest and V1 layers that are no longer referenced by a tagged layer.||Yes|
Maven - Delete SNAPSHOT
This task can be scheduled to delete SNAPSHOT components from a Maven repository. Typically this is useful to preserve storage space, as old SNAPSHOT versions are not accessed after deployment of a new snapshot and no longer add value. When you create a scheduled task to delete snapshots, you can specify the repository to affect, as well as set the following parameters:
Minimum snapshot count: This configuration option allows you to specify a minimum number of snapshots to preserve per component SNAPSHOT version.
Snapshot retention (days): This configuration option allows you to specify the number of days to retain component SNAPSHOT versions.
Remove if released: If checked, all SNAPSHOT versions that match any released component found with the same groupId and artifactId coordinates will be removed.
Grace period after release (days): This parameter allows you to specify a number of days before released snapshots are purged. If a release associated to a snapshot has an updated timestamp and falls within the set grace period, it will not be deleted. This setting will give the respective project that references the snapshot dependency time to upgrade to the release component or the next snapshot version.
The deletion of Maven snapshots when Remove if released is checked takes precedence over the number you select in the Minimum snapshot count field. NOTE: It is possible to configure the task in such a way that the results may be unexpected. If configured to keep 0 minimum snapshots older than 0 days, all snapshots everywhere will be deleted, despite whether or not a grace period is configured for releases.
The underlying soft-deleted blobs are permanently deleted using the strategy supported by the blobstore implementation.
Maven - Delete unused SNAPSHOT
This task can be used to delete unused SNAPSHOT components and assets from Maven repositories. Any SNAPSHOT version that has not been requested in the configured number of days will be affected. The underlying soft-deleted blobs are permanently deleted using the strategy supported by the blobstore implementation.
In the event the component has never been requested this task will use the uploaded date instead.
Maven - Publish Maven Indexer files
The task publishes the indexer files for all or a specific Maven repository.
Maven - Unpublish Maven Indexer files
|repository.maven.unpublish-dotindex||This task is the counterpart to the task Maven - Publish Maven Indexer files and can remove the indexer files.||Optional|
Repair - Rebuild Maven repository metadata (maven-metadata.xml)
|This task rebuilds the maven-metadata.xml files with the correct information and will also (optionally) validate and fix any incorrect checksums (.md5/.sha1) for all files in the specified maven2 hosted repository. The Group Id, Artifact Id and Base Version parameters allow you to narrow down the section of the repository that will be repaired. Typically this task is only run manually to repair a corrupted repository.||No|
Repair - Rebuild repository browse
|This task rebuilds the tree browsing data based upon current information in the database.||No|
Repair - Rebuild repository search
With support for hosted and proxy repositories, this task rebuilds the search index. It inspects actual components and assets found in the selected repository and thus reflects the true content for supporting search and browse actions.
Cancelling this task before completion could result in a partially rebuilt search index showing incomplete component search results until it is run again and allowed to complete.
Repair - Reconcile component database from blob store
This task allows you to recover lost asset/component metadata from a chosen blob store. The task is useful in cases where you have restored from backup, and the database and blob storage may be out of sync. This task should never be executed during normal operation of the server. When executed, the task searches the selected blob store for blobs missing their associated metadata. The asset/component metadata is restored based on the information contained in the blob store.
Currently, this task only recovers metadata for:
npm and Yum
npm and Yum search and tree view browsing will not work after running this task unless you run the respective metadata repair tasks ( Repair - Reconcile npm /-/v1/searchmetadata and Repair - Rebuild Yum repository metadata (repodata) ) first. Builds will work however.
Running these tasks before restore is complete will likely cause incomplete search and browse results.
NOTE: To avoid resultant possible errors in search and browse, we recommend running Repair - Rebuild repository browse and Repair - Rebuild repository search tasks when your component database repair is complete.
Repair - Reconcile date metadata from blob store
In NXRM 3.2.1 and earlier, it was possible to have uploaded asset records missing the creation date. This task was introduced in 3.6.1 specifically to read creationTime, createdBy and createdByIP values from asset blob properties files and update the affected asset records in the database. Asset records will only get updated if the asset record createdBy value is not set at all, otherwise asset records will not be modified by this task.
It is not recommended to run this task except for the specific use case it was designed for.
Repair - Reconcile npm /-/v1/searchmetadata
This task extracts search metadata from all npm packages in all npm hosted repositories to enable support for the new /v1/ search endpoint that replaced the /all/ endpoint.
Repair - Rebuild Yum repository metadata (repodata)
|This task rebuilds the metadata for a chosen Yum hosted repository. This task runs automatically 60 seconds (configurable) after an RPM is uploaded, deleted or redeployed.||No|
Repository - Delete unused components
This task can be used to delete components and assets in proxy repositories. Any component that has not been requested in the configured number of days will be soft-deleted. The underlying soft-deleted blobs are permanently deleted using the strategy supported by the blobstore implementation.
Older instances would typically schedule this but this is effectively replaced by the Cleanup feature.
Repository - Import external files
|repository.import||This task can be used to import external content into a Nexus Repository Manager instance. The external content must be laid out in the proper directory structure for the desired repository format. See Repository Import for more details.||No|
Repository - Export assets
|repository.export||This task can be used to export content from a repository. See Repository export for more details.||No|
A third-party plugin may provide additional scheduled tasks which will appear once you have installed the plugin.
Setting up task execution adapted to your usage of the repository manager is an important first step when setting up a Nexus Repository Manager instance. It is also important to update your tasks when changing your usage patterns. For example, adjustments to your tasks may be required if you start to regularly deploy snapshots by introducing continuous integration server builds with deployment.
The output of every task run will go to a separate log file. By default these task logs are stored in
$data-dir/log/tasks. The file name of each task log is the type followed by the full date and time the task started. For example:
Generally the output of the task will go to both the
nexus.log and the specific task log, however some tasks will only go to the
For long running tasks, progress will be logged back to the
nexus.log every 10 minutes as the work continues. Most commonly this will appear as a contextual update relevant to that particular task such as the number of items that have been processed, updated, deleted, etc.
Task log files are removed after 30 days.