In this article, we will briefly explain what unique snapshots in Artifactory are.
An artifact that has ‘SNAPSHOT’ appended to its file name right after the base revision is considered to be a snapshot artifact, i.e: dmm-libraries-scala-jpa-builder_2.10-0.13-SNAPSHOT.jar.
This filename is not unique. Normally, another artifact with the same name (i.e: next snapshot version) will overwrite the old one.
In order to allow you to keep older versions of snapshot artifacts, Artifactory calculates a timestamp and replaces the ‘SNAPSHOT’ with it at the time of deployment. This is so the new artifact does not overwrite the old one since it has a unique timestamp. The same timestamp will be given to a ‘batch’ of artifacts (usually deployed by the same build) and the timestamp will be bumped when Artifactory detects a new ‘batch’.
There are several ways in which Artifactory detects artifact ‘batches’ for the purpose of converting non-unique to unique snapshots. These mostly depend on the way the artifacts were deployed to Artifactory.
If you are, for testing purposes, deploying this snapshot from the UI, please make sure that each snapshot gets a new timestamp. If not, it will not be considered a new snapshot version and the cleanup will not be triggered. In this case, you would have to deploy the artifact and provide it with the timestamp. This can be done with the‘Deploy Artifact’ REST query using matrix params to add the timestamp as a property to the deployed file. For example:
curl -X PUT -uadmin:password -d@dmm-libraries-scala-jpa-builder_2.10-0.13-SNAPSHOT.jar “http://dominionmarinemedia.artifactoryonline.com/dominionmarinemedia/libs-snapshots-local/dmm/dmm-libraries-scala-jpa-testing_2.10/0.13-SNAPSHOT/dmm-libraries-scala-jpa-builder_2.10-0.13-SNAPSHOT.jar;build.timestamp=1404948018000“