-
Notifications
You must be signed in to change notification settings - Fork 164
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
Document reproducible builds #123
Conversation
- Fixes #112 Signed-off-by: Zander Mackie <zmackie@gmail.com>
|
||
### Consequences and Caveats | ||
|
||
We achieve reproducible builds by "zeroing" various timestamps of the layers that `pack` creates. When images are inspected (via something like `docker inspect`) they may have confusing creation times: |
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.
"layers that pack
creates" -- is all of the zeroing done by pack? I thought the exporter was responsible for some of this. I think it's worth being precise about this.
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.
I agree that being precise here is useful, but the fact that pack creates these layers via the lifecycle is getting a bit into the weeds for this is as a first pass. I was aiming for a higher level overview of the behavior that users will observe. That said, I the goal in getting this out is to point folks who have questions about reproducibility here and then further improve the documentation. I could very well image having a more technical/architectural explanation of this concept on this page at some later point, but I don't know if we need that right now.
All that said, I'm open to being wrong on that!
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.
Sounds good, we can always add more detail later :)
|
||
All that said, the CNB lifecycle cannot fix non-reproducible buildpack layer file contents. This means that the underlying buildpack and language ecosystem have to implement reproducible output (for example `go` binaries are reproducible by default). | ||
|
||
A local and remote build will not produce the same image digest because: |
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 is very interesting. If true, I think we should dig into it deeper. Why does the local image need to be an image ID instead of a reference? References can existing in the daemon. See docker tag
command.
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.
I think the key here is that local daemon stored images won't have a digest until pushed (this is because of docker):
○ → docker inspect cnbs/sample-builder:alpine | jq --raw-output '.[0].RepoDigests[]'
cnbs/sample-builder@sha256:9e3cfea3f90fb4fbbe855a2cc9ce505087ae10d6805cfcb44bd67a4b72628641
|2.6.3| NY-Floater-15565 in ~/workspace
○ → docker inspect cnb-test | jq --raw-output '.[0].RepoDigests[]'
Error: No such object: cnb-test
jq: error (at <stdin>:1): Cannot iterate over null (null)
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.
I did confirm that the runImage.reference
does change between whether you run pack build
or pack build ... --publish
. If we could calculate the image digest of a local image I'm curious why we don't. This is now totally irrelevant to this issue. Just something that was brought to light so thank you.
Signed-off-by: Zander Mackie <zmackie@gmail.com>
I created https://github.com/buildpacks/pack/issues/534 as a possible solution to the differences in config b/w locally and remotely created images. |
Signed-off-by: Zander Mackie <zmackie@gmail.com>
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.
I added two minor comments but the document is very clear.
Signed-off-by: Zander Mackie <zmackie@gmail.com>
Signed-off-by: Zander Mackie zmackie@gmail.com