-
Notifications
You must be signed in to change notification settings - Fork 18.9k
vendor: update buildkit to v0.11.2 #44686
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
Conversation
da18165 to
33cd806
Compare
|
There are a couple of test failures. Investigating. |
thaJeztah
left a comment
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.
thanks! left some comments/questions
| } | ||
|
|
||
| func (e *imageExporterInstance) Export(ctx context.Context, inp exporter.Source, sessionID string) (map[string]string, error) { | ||
| func (e *imageExporterInstance) Export(ctx context.Context, inp *exporter.Source, sessionID string) (map[string]string, exporter.DescriptorReference, error) { |
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 signature is starting to look a bit awkward; I had a quick look, and it seems this is ultimately defined in the BuildKit repository. As it's being updated already, would it make sense to have a struct definition for the returned values (which contains both the map[string]string and the DescriptoReference) work?
I haven't looked very closely, but the existing map[string]string returns this;
return map[string]string{
exptypes.ExporterImageConfigDigestKey: configDigest.String(),
exptypes.ExporterImageDigestKey: id.String(),
}Which feels like it was intended as a "generic" key/value list (maybe I'm wrong though), so perhaps the map could be a map[string]interface instead, OR ( if the "what should be returned" should be more formal) the map could be discarded and individual fields defined for them.
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.
These are for different use cases. Map is for the client to handle metadata while the new field in for buildkit internal post-processing that runs after the exporter. If there are more fields for post-processing in the future, then the new field should be turned into struct instead of adding a 4th var.
| hconf = &bkconfig.HistoryConfig{ | ||
| MaxAge: int64(opt.BuilderConfig.History.MaxAge), | ||
| MaxEntries: int64(opt.BuilderConfig.History.MaxEntries), | ||
| } |
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.
Should we change the opt.BuilderConfig.History type to match, so that we don't have to cast to an int64 ?
| // BuilderHistoryConfig contains history config for a buildkit builder | ||
| type BuilderHistoryConfig struct { | ||
| MaxAge int `json:",omitempty"` | ||
| MaxEntries int `json:",omitempty"` | ||
| } |
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.
Oh! And I just realise that's a new type; any reason for using int here (instead of int64)?
Potentially this could even be an alias for the buildkit type (cmd/buildkitd/config.HistoryConfig), although if it becomes a public API, perhaps that config package should be moved outside of cmd as it looks it's no longer really a command-line config only (but options for a buildkit instance)
| func init() { | ||
| version.Version = "v0.11.0-rc3" | ||
| } | ||
|
|
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.
Should we have a plain var for this, so that it can be through a -X option at compile time?
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.
If you want to set it with -X then I think you can just set the version.Version directly there. Or is there any problem with -X not working with vendored packages?
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 was wondering that indeed; wasn't sure if it would allow setting things in vendor.
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 it's fine, maybe also add a comment in vendor.mod:
Line 54 in b9fe30d
| github.com/moby/buildkit v0.10.6 |
to not forget to also update this.
| func (w *Worker) BuildkitVersion() client.BuildkitVersion { | ||
| return client.BuildkitVersion{ | ||
| Package: version.Package, | ||
| Version: version.Version + "-moby", |
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.
Still wondering a bit if -moby would already be reflected from the builder type (container vs docker / moby)
| return client.BuildkitVersion{ | ||
| Package: version.Package, | ||
| Version: version.Version + "-moby", | ||
| Revision: version.Revision, |
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 probably needs packaging changes to propagate the version (as the version from the vendored BuildKit code won't be set) 🤔
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.
Hum yes we might need smth like: crazy-max@59746a8
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.
@crazy-max remind me to this one 😅
builder/builder-next/controller.go
Outdated
| return nil, err | ||
| } | ||
|
|
||
| historyDB, err := bbolt.Open(filepath.Join(opt.Root, "history.db"), 0600, nil) |
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.
Nit; should use the new 0o format (linters start to expect these, so we may as well be ahead of some of that)
| historyDB, err := bbolt.Open(filepath.Join(opt.Root, "history.db"), 0600, nil) | |
| historyDB, err := bbolt.Open(filepath.Join(opt.Root, "history.db"), 0o600, nil) |
Also; question: is there code somewhere to clean up these files and/or truncate them? I was wondering what these contain, and if (some of) these should be / become part of docker builder prune or docker system prune, or perhaps even should be deleted on daemon restart (maybe we do some of that already, haven't checked).
33cd806 to
13d274b
Compare
13d274b to
36f4f3f
Compare
36f4f3f to
fdee00a
Compare
full diff: tonistiigi/fsutil@9ed6126...0127568 Signed-off-by: Sebastiaan van Stijn <[email protected]> Signed-off-by: Tonis Tiigi <[email protected]>
Signed-off-by: Tonis Tiigi <[email protected]>
fdee00a to
99ff094
Compare
Signed-off-by: Tonis Tiigi <[email protected]>
99ff094 to
043dbc0
Compare
|
Green now. |
| echo "BUILDKIT_REPO=tonistiigi/buildkit" >> $GITHUB_ENV | ||
| echo "BUILDKIT_REF=db67180a1a439efb1547ecf5decd4003ec8f621b" >> $GITHUB_ENV |
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.
Note to self; we can remove this once moby/buildkit#3567 is merged and cherry-picked in the 0.11 branch
thaJeztah
left a comment
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.
LGTM, thanks!
Uh oh!
There was an error while loading. Please reload this page.