Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Make image builds reproducible #4142
Make image builds reproducible #4142
Changes from all commits
095343c
6376c32
05bd7f8
9f048d1
24162dd
8175386
de4ab25
dc3633b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the regular use is to force setting the file timestamp to epoch+1 by default. The only other alternative for the user is to set a static time. Jib never sets the original timestamp of the source file.
From the Jib plugin doc:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I can see my comment was a bit unclear. What I meant was that in normal use, Jib reads in files from disk and they have some "real" modification time. Then Jib is supposed to reset this, but that didn't happen (or at least didn't happen "enough" because there were still PAX headers with the timestamps in them).
Because the test helper created test files where the modtime was already reset, this issue wasn't visible in the test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does happen. To clarify, the ordinary modification time is correctly set to epoch+1. It's just that the newer apache compress library added or set some new PAX headers with timestamp values. AFAICT, the mod time and the time values in PAX headers are independent. Everything worked fine without this PR, except that the new headers had dynamic values hence affected reproducibility. As long as we set the ordinary mod time to epoch+1, I think it shouldn't matter what time you set for the PAX headers. So ideally, I think what we need to test is these two:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ad 1: The PAX headers take precedence it seems, so I'll set them to 1 and try to switch the ordering like you suggested below 👍
Ad 2: I believe that testing the wiping of the headers is captured in the existing test case
testToBlob_reproducibility
, as it compares the raw bytes. This test would fail after I updated the helper function here, hence my point with the old version of this helper "hiding" the issue with PAX headers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
testToBlob_reproducibility
fails because of mismatched byte arrays. So I'd argue that this is covered as well :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes of course, I forgot that it's user-configurable 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although - I'm a bit at a loss as to where the modTime is supposed to be reset. In line 79 and 167 in
ReproducibleLayerBuilder.kt
there are calls to.setModTime
. In the former case, for directories, it's always set to EPOCH+1 regardless of any user settings. In the latter case, for files, it's always set to the file's real value on disk, which is not reproducible. Are there any other places in the code base where the modification time could've been reset?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
167 is the user-configured value. Just set both the PAX headers and
setModTime()
to the same timestamp. For the (Jib-created) directiories, it is not customizable and always set to epoch+1.To recap, just set the same value as Jib does now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @chanseokoh - I've been away from this work for a while due to other things. I've read the code more carefully now and I'll now understand that I was confused earlier as to where the responsibility of (re)setting the datetime lies. I'll set the PAX headers to the same timestamp as setModTime 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bjornbugge too bad that you missed the release 3.4.1.