Trouble deploying snapshot from Bamboo to Artifactory

4
votes

I would like to deploy snapshot builds from Bamboo to Artifactory. My repository's Handle Snapshots option is checked and it's Maven Snapshot Version Behavior is set to Unique. The repository's layout is gradle-default.

My goal is for a build plan to deploy an artifact at a location similar to the following:

repo-local:com.company/project/1.0-SNAPSHOT/project-1.0-20120612.101600.txt

In Bamboo I have a Artifactory Generic Deploy Task, configured with the following for the Edit Published Artifacts field:

project-1.0-SNAPSHOT.txt=>com.company/project/1.0-SNAPSHOT

However Artifactory rejects my build artifacts, saying The repository 'repo-local' rejected the artifact 'repo-local:com.company/project/1.0-SNAPSHOT/project-1.0-SNAPSHOT.txt' due to its snapshot/release handling policy.

How do I get Artifactory to accept the artifact and automatically replace SNAPSHOT with a timestamp in the filename?

1
bambooartifactory

1 Answers

4
votes

Your problem is most likely the fact that the path you deploy to is not considered a valid integration revision by the layout you've selected (gradle-default). The gradle-default layout expects integration revisions like:

org/module/1.0-12345678912345/module-1.0-12345678912345.jar

That is, for a 14 digit long time stamp to be appended after the base revision; While your path contains SNAPSHOT instead of a 14 digit long timestamp.

If you want to have pattern like:

com.company/project/1.0-SNAPSHOT/project-1.0-20120612.101600.txt

You will have to customize the layout to accept -SNAPSHOT as the folder integration revision and modify your artifact to contain a timestamp as the file integration revision.

I'm guessing your assumption was that Artifactory will convert the non-unique integration revision to a unique one; Artifactory performs this conversion only when the repository is set to the default Maven layout and when the artifacts adhere to Maven's layout.

This is due to the fact the while Maven actually has defined standards for integration revisions, Gradle do not have such a standard; So basically, a Gradle revision could be practically anything.

On top of that, the concept of unique and non-unique integration revisions doesn't really exist in the Gradle world, it doesn't actually have any built-on functionality to support these features; and so when you see a Mavenized path in Gradle, it's just basically mimicking the pattern.