-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Builds not reproducible #4141
Comments
Looks like this is a duplicate of #4131. The PR makes sense, and if it works, I think it would close both this and #4131. Then the question is, does your PR #4142 work with the current apache-commons-compress version in this repo? That is, do those methods exist in the current library version? Otherwise, the PR needs to bump the version. |
So it is! :) It works with the current version of apache-commons-compress yes. It's hard to write a unit test that provokes the bug with anything other than the |
I've been investigating a similar issue and see this with files copied in via
The birth and change times are not stable even though the file digests are the same and reproducible flags are set
Stating the extra files
|
I just lost several hours to this. It would be good to get it fixed since projects are upgrading commons-compress due to CVEs: davidmc24/gradle-avro-plugin@7362bf7 |
Does anyone have a workaround to this, until #4142 is fixed? I am finding it really hard to figure out how to pin this dependency to 1.21 in Gradle. |
@glasser i was able to override the commons version but have jib configured in a build convention / plugin so there's an added layer of indirection. I'm not sure how to do this as a standalone plugin dependency within a module, but pinning to 1.21 in my build convention's build.gradle seems to have worked with back-to-back builds. Removing the version pinning block results in the original issue of different digests for one of the layers. HTH, build convention's build.gradle:
I confirmed this with the |
@chanseokoh Are there any steps I need to take in order to get #4142 merged? As far as I can see it is awaiting review/approval by maintainers. |
Just nag the maintainers loudly. |
Thanks for your patience on this @bjornbugge! We've reviewed your PR. There are a few tests failing during to a checkstyle issue. |
@mpeddada1 nag() |
Thanks for the follow up @izogfi ! Reviewed #4204. |
@mpeddada1 I updated #4204. Please take another look. |
Environment:
Description of the issue:
Some of the Docker image layers are given new sha256-hashes when invoking jib after a
./gradlew clean
but otherwise do not make any changes. Locally it appears to be a layer that contains the output of aCopy
task that changes checksum, but the file itself remains the same, with the same checksum. Even worse, on CI it's the "bottom" layer with the external libraries that change on every single build.Expected behavior:
Invoking Jib twice on the same git rev and with the same parameters should yield the same image every time.
Probable cause
When inspecting the individual layers from the
jibBuildTar
task it seems that the culprits are theatime
,mtime
,ctime
, andLIBARCHIVE.creationtime
tar headers. They change between the builds dependning on whether input files have been deleted and recreated again. These headers should probably be cleared inReproducibleLayerBuilder::setUserAndGroup
where the username/group info is also cleared.The text was updated successfully, but these errors were encountered: