I’ve see a lot written about how gradle uses sha1 hashes to identify cached artifacts and to detect when an artifact needs to be downloaded. But I can’t find anything that says if those hashes can also be used to actually validate artifacts.
I tried the following:
Publish an artifact via gradle to a local ivy repo.
In the repo, modify the uploaded sha1 file, effectively “corrupting” the artifact.
In a second build I declared a dependency on the artifact.
Gradle seemed happy to download the artifact even though it’s computed sha1 should now appear invalid relative to the sha1 in the repo. Is there an (easy) way to make the build fail in the event of such a sha1 mismatch?
It still seems odd to me though - since gradle goes through the trouble of computing and comparing hashes for the sake of cache validation, wouldn’t it be both easy and prudent to use those same hashes to ensure the the artifact was downloaded w/out corruption?
Is the idea that in the case of a bad download, then the next time you run the build, the local/remote hashes won’t match and it’ll download again? Wouldn’t it be better to catch that problem immediately and stop the initial build or retry the download?
It seems like right now there’s potential for a corrupt download to get into the cache and for the build to happily continue to run against that artifact.