Generate and embed build sources#2311
Conversation
tonistiigi
left a comment
There was a problem hiding this comment.
@thaJeztah @AkihiroSuda Please verify you're ok with the keys in the config structure.
I see some TODOs still left. In addition, needs integration tests.
Wonder if we should merge containerimage.buildinfo/* to a single containerimage.buildinfo key.
Different platforms can have different dependencies.
tonistiigi
left a comment
There was a problem hiding this comment.
We also need to add an exporter option for opt-out.
4e3d1f4 to
e9767fb
Compare
thaJeztah
left a comment
There was a problem hiding this comment.
Left some random thoughts.
Also wondering; should this be a field in the image, or should they be stored as annotation / label? (label org.mobyproject.buildkit.buildinfo.v0=<data>, or a com.docker. reserved prefix. When doing so, we need to take into account that containerd limits label data to 4k (if I remember correctly)
6c85966 to
61158d5
Compare
This is not human-readable so it should produce extra noise for the user. I guess the inline cache variant also can easily hit size limits. |
61158d5 to
7fdd8cc
Compare
Agreed, it's not human readable; that said, labels were to add metadata, which not necessarily has to be human-readable. Wouldn't the same apply to the current field (showing up in |
|
Basically, my concern was that Will that cause issues? |
Don't think it should as this is BuildKit specific and unknown fields in the oci spec are skipped afaik. |
c9bff8b to
1ef01a3
Compare
I do think labels/annotations are human-readable and searchable by definition. This is just noise as it is an encoded field. Possibly very large as well. Cache/opts will be larger than this buidinfo but they should all use the same pattern.
It should not show up in docker inspect atm (same as cache). Inspect does not show raw config.
Lots of Dockerfile fields are not. This is buildkit specific so we shouldn't use a field that could collide with something else. |
1633ae6 to
6f3c815
Compare
1000f5e to
1bb9a73
Compare
f7b3770 to
bdb7ddb
Compare
125967e to
cdd00d2
Compare
cdd00d2 to
06d50f1
Compare
| inp.Ref = workerRef.ImmutableRef | ||
|
|
||
| dt, err := inlineCache(ctx, exp.CacheExporter, r, session.NewGroup(sessionID)) | ||
| dtbi, err := buildinfo.Merge(ctx, res.BuildInfo(), inp.Metadata[exptypes.ExporterImageConfigKey]) |
There was a problem hiding this comment.
why can't this be just inside the imagewriter exporter?
There was a problem hiding this comment.
we need the merged result for the exporter response too (metadata).
There was a problem hiding this comment.
but metadata is also returned by the exporter
There was a problem hiding this comment.
I guess I done that in the solver to avoid changing the ExporterInstance.Export signature because ResultProxy is not passed to it. Do you see any downside about it?
There was a problem hiding this comment.
Not a strict requirement but thought it could be cleaner. You can test in a follow-up and see if it improves.
| case *source.ImageIdentifier: | ||
| for _, bi := range icbi { | ||
| // Use original user input from image config | ||
| if bi.Type == exptypes.BuildInfoTypeDockerImage && bi.Alias == sid.Reference.String() { |
There was a problem hiding this comment.
this reference does not need TagNameOnly ?
There was a problem hiding this comment.
no we want to match the alias which is the actual ref.
There was a problem hiding this comment.
What is "actual ref" in here. TagNameOnly would mean we normalize both sides.
There was a problem hiding this comment.
The pseudo-ref from alias sorry which is retrieved from ResolveImageConfig in the frontend and will match the one from LLB.
07272d1 to
d269a38
Compare
4d50ac6 to
be2fc19
Compare
be2fc19 to
5b990eb
Compare
5b990eb to
d990c9c
Compare
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
d990c9c to
5fcc944
Compare
Fixes #2269
crazymax/buildkit:buildsourcescrazymax/dockerfile:masterCreate and boot builder:
Build image:
Image config generated with the above command:
moby.buildkit.buildinfo.v0is a single base64 encoded string and will look like this with the above response:{ "sources": [ { "type": "image", "ref": "docker.io/docker/buildx-bin:0.6.1@sha256:a652ced4a4141977c7daaed0a074dcd9844a78d7d2615465b12f433ae6dd29f0", "pin": "sha256:a652ced4a4141977c7daaed0a074dcd9844a78d7d2615465b12f433ae6dd29f0" }, { "type": "image", "ref": "docker.io/library/alpine:3.13", "pin": "sha256:1d30d1ba3cb90962067e9b29491fbd56997979d54376f23f01448b5c5cd8b462" }, { "type": "image", "ref": "docker.io/moby/buildkit:v0.9.0", "pin": "sha256:8dc668e7f66db1c044aadbed306020743516a94848793e0f81f94a087ee78cab" }, { "type": "image", "ref": "docker.io/tonistiigi/xx@sha256:21a61be4744f6531cb5f33b0e6f40ede41fa3a1b8c82d5946178f80cc84bfc04", "pin": "sha256:21a61be4744f6531cb5f33b0e6f40ede41fa3a1b8c82d5946178f80cc84bfc04" }, { "type": "git", "ref": "https://github.com/crazy-max/buildkit-buildsources-test.git#master", "pin": "259a5aa5aa5bb3562d12cc631fe399f4788642c1" }, { "type": "http", "ref": "https://raw.githubusercontent.com/moby/moby/master/README.md", "pin": "sha256:419455202b0ef97e480d7f8199b26a721a417818bc0e2d106975f74323f25e6c" } ] }ExporterResponsealso contains a new keycontainerimage.buildinfoif we want to use it in theclient.SolveResponse:containerimage.buildinfois also a single base64 encoded string likemoby.buildkit.buildinfo.v0.Multi-platform is also handled:
Each image config will have the same structure but
ExporterResponsewill have a key for each platform:Wonder if we should merge
containerimage.buildinfo/*to a singlecontainerimage.buildinfokey.