ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrice Matignon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IVY-1466) overwrite flag causes publish failure for repositories which autogenerate checksums
Date Fri, 04 Apr 2014 21:47:15 GMT

    [ https://issues.apache.org/jira/browse/IVY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960460#comment-13960460
] 

Patrice Matignon commented on IVY-1466:
---------------------------------------

I'm not sure this is the error you're seeing.

>From my Artifactory 2.9 instance, I can go to Admin -> Repository , 'Edit' my repo
and open up the properties dialog.
There, a "checksum policy" field has the following tooltip text:

"Checksum policy determines how Artifactory behaves when a client checksum for a deployed
resource is missing or conflicts with the locally calculated checksum (bad checksum).
Checksum checking effectively verifies the integrity of the deployed resource.
The options are:
(1) Verify against client checksums (default) - Until a client has sent a valid checksum
for a deployed artifact that matches the server's locally calculated checksum, the
artifact's checksum will not be available and will return 404 (not found).
If the client has sent a checksum that conflicts with the one calculated on the server a
409 (conflict) will be returned until a valid checksum is deployed.
(2) Trust server generated checksums - Do not verify against checksums sent by clients
and trust the ones store server's locally calculated checksums. An uploaded artifact
will be available for consumption immediately, but integrity might be compromised.
"

So I think for another workaround you can try (2) "trust server checksums", so Artifactory
will ignore (hopefully silently) your client-provided checksums.

Also, If you have (1) "Verify against client checksums (default) ", it is possible that the
Ivy client checks to see if 1) the checksums mismatch (would expect a 409=mismatch, reject)
and 2) are generated or not (2xx=generated by server, 404=not generated). In the case the
checksums are generated I think a proper behavior fo rhte Ivy client would be to download
them and compare with the client checksums instead of uploading them.
Now, this is pure conjecture, but I thought it could be valuable before going thru the Ivy
client code if you were going to.



> overwrite flag causes publish failure for repositories which autogenerate checksums
> -----------------------------------------------------------------------------------
>
>                 Key: IVY-1466
>                 URL: https://issues.apache.org/jira/browse/IVY-1466
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.4.0-RC1
>         Environment: Ubuntu, Artifactory (maven or ivy), server-generated checksums enabled
(since maven also published to the repo)
>            Reporter: Joshua Suereth
>
> When publishing to a repository with "overwrite" set to false, Ivy publishes the artifact
*then* checks to see if the checksum file exists.   Since Artifactory automatically creates
the checksums, this leads to a failure to publish because the checksum already exists.
> I see two possible fixes:
> 1) Publish signatures/checksums first (I think this may cause other issues with things
like nexus/artifactory
> 2) If you succeed to publish the artifact with the correct overwrite flag, then ALWAYS
overwrite when publishing the checksums (since you just pushed the artifact).  There's really
no reason not to, and it could cause problems if you don't.
> We're taking option #2 in sbt, see our hacky workaround here: https://github.com/sbt/sbt/pull/1232/files#diff-b50b19f131fece36d762990bd9d34625R77



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message