Skip to content

Conversation

@tonistiigi
Copy link
Member

@tonistiigi tonistiigi commented Dec 22, 2022

@tonistiigi tonistiigi force-pushed the buildkit-update-v0.11-rc3 branch from da18165 to 33cd806 Compare December 22, 2022 02:43
@tonistiigi
Copy link
Member Author

There are a couple of test failures. Investigating.

Copy link
Member

@thaJeztah thaJeztah left a 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) {
Copy link
Member

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.

Copy link
Member Author

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.

Comment on lines 216 to 219
hconf = &bkconfig.HistoryConfig{
MaxAge: int64(opt.BuilderConfig.History.MaxAge),
MaxEntries: int64(opt.BuilderConfig.History.MaxEntries),
}
Copy link
Member

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 ?

Comment on lines 63 to 67
// BuilderHistoryConfig contains history config for a buildkit builder
type BuilderHistoryConfig struct {
MaxAge int `json:",omitempty"`
MaxEntries int `json:",omitempty"`
}
Copy link
Member

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)

Comment on lines +51 to +54
func init() {
version.Version = "v0.11.0-rc3"
}

Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member

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:

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",
Copy link
Member

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,
Copy link
Member

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) 🤔

Copy link
Member

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

Copy link
Member

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 😅

return nil, err
}

historyDB, err := bbolt.Open(filepath.Join(opt.Root, "history.db"), 0600, nil)
Copy link
Member

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)

Suggested change
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).

@tonistiigi tonistiigi force-pushed the buildkit-update-v0.11-rc3 branch from 13d274b to 36f4f3f Compare January 19, 2023 00:57
@tonistiigi tonistiigi changed the title vendor: update buildkit to v0.11.0-rc3 vendor: update buildkit to v0.11.1 Jan 19, 2023
@thaJeztah thaJeztah added this to the v-next milestone Jan 20, 2023
@tonistiigi tonistiigi force-pushed the buildkit-update-v0.11-rc3 branch from 36f4f3f to fdee00a Compare February 2, 2023 07:10
@tonistiigi tonistiigi force-pushed the buildkit-update-v0.11-rc3 branch from fdee00a to 99ff094 Compare February 2, 2023 07:29
@tonistiigi tonistiigi force-pushed the buildkit-update-v0.11-rc3 branch from 99ff094 to 043dbc0 Compare February 2, 2023 07:57
@tonistiigi tonistiigi changed the title vendor: update buildkit to v0.11.1 vendor: update buildkit to v0.11.2 Feb 2, 2023
@tonistiigi
Copy link
Member Author

Green now.

Comment on lines +75 to +76
echo "BUILDKIT_REPO=tonistiigi/buildkit" >> $GITHUB_ENV
echo "BUILDKIT_REF=db67180a1a439efb1547ecf5decd4003ec8f621b" >> $GITHUB_ENV
Copy link
Member

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

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants