Skip to content

Force ChecksumDeploy #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
staffanf opened this issue Apr 27, 2020 · 9 comments · Fixed by #408
Open

Force ChecksumDeploy #341

staffanf opened this issue Apr 27, 2020 · 9 comments · Fixed by #408
Assignees

Comments

@staffanf
Copy link

staffanf commented Apr 27, 2020

Hi, I would like an option to force the use of "X-Checksum-Deploy".
Currently this seems to be used if the files are larger than 10KB due to the CHECKSUM_DEPLOY_MIN_FILE_SIZE contant.

This is a fine default trade-off between bandwidth and latency I guess, but my use-case is that I want builds to be reproducible and retryable while still not being able to overwrite artifacts.
So If a jar is smaller than 10Kb, then checksum deploy will not be used and the a completely identical build will fail if published again.
I would like a developer build or a ci jobs to be re-runnable as long as the build artifacts are identical.

I'm using the Gradle Plugin btw.

Just changing the constant referenced above to something that is configurable would at least make this possible for by setting CHECKSUM_DEPLOY_MIN_FILE_SIZE to 0.

If there is a another way to solve my use-case or a temporary workaround, please advice.

@staffanf
Copy link
Author

staffanf commented Nov 5, 2020

@yahavi Is this something you could comment on?

@yahavi
Copy link
Member

yahavi commented Nov 6, 2020

Hello @staffanf,
Sorry for the late response.

We have this functionality in the JFrog CLI, using JFROG_CLI_MIN_CHECKSUM_DEPLOY_SIZE_KB environment variable. Therefore I think it is reasonable to have it in the Gradle plugin as well.

I created #408 to add this functionality. Please let me know if that's what you're looking for.
Thanks!

@yahavi yahavi linked a pull request Nov 30, 2020 that will close this issue
1 task
@yahavi yahavi self-assigned this Nov 30, 2020
@yahavi
Copy link
Member

yahavi commented Dec 1, 2020

@staffanf,
Gradle Artifactory plugin 4.18.2 is released. This release includes #408. Documentation will be updated soon.
In order to force checksum download and make sure identical artifacts will not be overridden in Artifactory, you can use the following configuration in your build.gradle:

allProjects {
    artifactoryPublish {
        clientConfig.publisher.minChecksumDeploySizeKb = 0
    }
}

We'd appreciate your feedback for that!

@paul-hammant
Copy link

Checksum is the SHA-1 or something else?

@yahavi
Copy link
Member

yahavi commented Jan 18, 2021

@paul-hammant
The Artifactory Maven and Gradle plugins compare either SHA1 and MD5 - an artifact does not upload if both SHA1 and MD5 exist in Artifactory.

@paul-hammant
Copy link

OK, an artifact does not upload if both SHA1 and MD5 exist in Artifactory and are the same local and remote

If the artifact exists in Artifactory, and the SHA1 is different, then the build step fails at that moment - right?

@yahavi
Copy link
Member

yahavi commented Jan 18, 2021

OK, an artifact does not upload if both SHA1 and MD5 exist in Artifactory and are the same local and remote

Yes, exactly.

If the artifact exists in Artifactory, and the SHA1 is different, then the build step fails at that moment - right?

Yes, if the artifact already exists in the same deployment path and the deployer user does not possess Delete/Overwrite permission to the repository.

@saper
Copy link

saper commented Sep 8, 2022

Is there anyway to use this in the Jenkins Artifactory plugin? At minimum, supply the checksum not to override file if it is the same?

@paul-hammant
Copy link

F/OSS allows us to fork items and add features for ourselves. Might have to worry about trademarks as the forkers publish back to mavenland, and divergence after but there's not reason not to if upstream maintainer are not keen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants