Closed gojihotsauce closed 6 years ago
draft up
has a bunch of option flags for communicating with a docker daemon, so if it's feasible to do the same with injecting build arguments I don't see why not.
If you're up to take a crack at this, you can have a look here on how we set up the docker CLI: https://github.com/Azure/draft/blob/master/cmd/draft/up.go
Another place to take a look about build options for Docker is - https://github.com/Azure/draft/blob/master/pkg/builder/docker/builder.go#L35
I've investigated what would take to add the build arguments and it's a matter of adding them to draft.toml
and parsing them as BuildArgs map[string]*string
(from ImageBuildOptions
).
The Azure Container Builder has a different object type for the build arguments, BuildArguments *[]BuildArgument
, where BuildArgument
is :
type BuildArgument struct {
// Type - The type of the argument.
Type *string `json:"type,omitempty"`
// Name - The name of the argument.
Name *string `json:"name,omitempty"`
// Value - The value of the argument.
Value *string `json:"value,omitempty"`
// IsSecret - Flag to indicate whether the argument represents a secret and want to be removed from build logs.
IsSecret *bool `json:"isSecret,omitempty"`
}
In theory (haven't tested this), it means we can pass secret build arguments to the Azure Builder and those secrets will not persist in the built image layers - this contrasting with the default Docker behavior.
Hi, @debtcollapse! Just merged support for Docker build arguments, give it a try and let us know if it solves your use case 😄
My organization is in the process of evaluating draft and so far we are extremely happy with it.
I ran into an issue today where one of our developers asked me about authenticating to a private node module registry during the docker build phase of
draft up
.The official node documentation recommends passing the npm token as a
--build-arg
, which doesn't appear to be supported bydraft up
.We have a couple of ugly workarounds that we've been toying with but It would be great to be able to leverage the full range of docker build options (not just
--build-arg
) as there are likely many other use cases out there waiting to be discovered.