SHA1 mismatch when publishing to Ivy Artifactory repository

I have an Artifactory (2.6.4) ivy-default repository. Occasionally, when I publish to it I get this kind of error:

Execution failed for task ':uploadArchives'.
> Could not publish configuration ':compile'.
   > Could not PUT '<my repo>/libs-integration-local/org.gradle.test/bad
_ivy_publish_to_artifactory/1.0/'. Received status code 409 from server: Checksum error for 'org
.gradle.test/bad_ivy_publish_to_artifactory/1.0/': received '57421358918d00830260fe88600de698673
b0db' but actual is '057421358918d00830260fe88600de698673b0db'

I have produced a small build script to reproduce this problem. You will need to install Artifactory and set up an ivy repository.

version = '1.0'
group = 'org.gradle.test'
  configurations {
  task theZip(type: Zip) {
    baseName = 'the_zip'
    from "thing.txt"
    classifier = 'src'
  artifacts {
    compile theZip
  uploadArchives {
    configuration = configurations.compile
    uploadDescriptor = true
    repositories {
        ivy {
            credentials {
                username <my user name>
                password <my encrypted password>
            url <my artifactory repository>

You also need to create a file called ‘thing.txt’ alongside the ‘build.gradle’. It should contain exactly this text (with no end-of-line characters):

I cause a bad SHA1

I tried lots of different file contents to reproduce the problem. For me, this was reproducably giving a SHA1 of 57421358918d00830260fe88600de698673b0db, which is 39 characters long. Artifactory’s SHA1 algorithm puts a leading zero at the beginning to make the SHA1 40 characters long. So, if for some reason you don’t get the same hash as me, keep changing the contents of ‘thing.txt’ until you do - I expect that it will fail one in 16 times on average.

I can work around this by telling Artifactory to ‘trust server generated checksums’. Is there anything you can do to fix this, or is this really a bug in Artifactory?

Hello Neil, you’re running into We fixed this already on master. can you give a latest nightly build a try to doublecheck that the fix is working for you?

cheers, rené

Yes, Gradle 1.3-20121021220010+0000 has fixed this issue.