-
Notifications
You must be signed in to change notification settings - Fork 485
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
bake: switch to controller #1861
base: master
Are you sure you want to change the base?
Conversation
5d4b713
to
1c7055c
Compare
c03f580
to
8852925
Compare
controller/build/build.go
Outdated
func RunBuild(ctx context.Context, dockerCli command.Cli, in controllerapi.BuildOptions, inStream io.Reader, progress progress.Writer, generateResult bool) (*client.SolveResponse, *build.ResultContext, error) { | ||
if in.NoCache && len(in.NoCacheFilter) > 0 { | ||
return nil, nil, errors.Errorf("--no-cache and --no-cache-filter cannot currently be used together") | ||
func RunBuild(ctx context.Context, dockerCli command.Cli, builderName string, in *controllerapi.BuildOptions, inStream io.Reader, progress progress.Writer, generateResult bool) (*client.SolveResponse, *build.ResultContext, 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.
Why do we need to have a separated builderName
option? This looks already included in the controllerapi.BuildOptions
.
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 looking at passing just the list of nodes necessary to build so we don't create another builder instance. But when building multiple targets controller.BuildOptions is a map and I don't think having Builder there is right:
buildx/controller/pb/controller.proto
Line 74 in 0758a9b
string Builder = 23; |
I will take another look to improve this.
8852925
to
a481e15
Compare
This patch continues the move to attempt to merge the build.Options struct into the controllerapi.Options message. To do this, we extract all the input parameters into a dedicated message (adding the missing ones, except for the InStream parameter which will require some additional fiddling around). We also rework the NamedContexts to allow containing States (by transmitting them as DefinitionOps), and adding a Linked field to the common options. Signed-off-by: CrazyMax <[email protected]>
With the previous changes to bring controllerapi.BuildOptions up to date with build.Options, we can have bake generate controllerapi.BuildOptions, and then convert those to build.Option using the controller/build package. This is an intermediate patch, designed to allow us to clean up some shared logic between both build and bake. The next step will be to modify bake to use the controller api, and completely skip the build.Options generation step. Signed-off-by: CrazyMax <[email protected]>
With this change we are now passing a list of controller options to run a build and returns a map of responses and result context as bake can handle a list of targets. Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
a481e15
to
e16151f
Compare
Carry #1680 to handle controller options with bake and also use controller to build. This will be used in #1841 so we can pass the build reference to the result context for both build and bake efficiently.