build-info
build-info copied to clipboard
Force ChecksumDeploy
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.
@yahavi Is this something you could comment on?
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 https://github.com/jfrog/build-info/pull/408 to add this functionality. Please let me know if that's what you're looking for. Thanks!
@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!
Checksum is the SHA-1 or something else?
@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.
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?
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.
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?
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