-
Notifications
You must be signed in to change notification settings - Fork 147
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
SUP-2585: Add Support for changing Build Drivers #463
Conversation
…river Signed-off-by: Tom Watt <tom@buildkite.com>
59c0543
to
52d193d
Compare
…nd removing duplication
… flexibility with parameters
…se across different hooks
…nstead of removing them always as they need to exist for cache
Bringing out of Draft for initial reviews whilst adding tests |
Signed-off-by: Tom Watt <tom@buildkite.com>
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.
Despite all my comments, this is a very thorough implementation of the functionality 🎉
hooks/pre-command
Outdated
valid_drivers="docker-container|kubernetes|remote" | ||
if [[ "${build_driver}" =~ ^(${valid_drivers})$ ]]; then | ||
builder_instance_args=(--driver "${build_driver}") | ||
else | ||
echo "+++ 🚨 Invalid driver: '${build_driver}'" | ||
echo "Valid Drivers: ${valid_drivers//|/, }" | ||
exit 1 | ||
fi |
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 am not sure if it is a good idea to validate options for a string we do not control and that people could modify in their docker installation.
Note: I'm OK with leaving this as-is, but we might want to remove it if we find that we have to keep updating it or some user complains about not being able to use a custom one
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.
Yeah feeling the same too as well, haven't came across other Driver documentation that's wildly available though aware there is the cloud
as well so only included those well documented available for starting off and helping scope the changed
$ docker buildx create --help
...
...
--driver string Driver to use (available: "cloud", "docker-container", "kubernetes", "remote")
...
...
But if you feel we should make make it more generic, it does simplfy logic and makes the Docker engine itself more responsible for the error messaging e.g.,
$ docker buildx create --name test --driver-opt memory=100m,cpuset-cpus=1 --driver test
ERROR: failed to find driver "test"
… already existing
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.
👏 very thorough second round... most of my comments are cosmetic or enhancements to what is already there so feel free to leave them for future improvements
Co-authored-by: Matías Bellone <toote@users.noreply.github.com>
Co-authored-by: Matías Bellone <toote@users.noreply.github.com>
Signed-off-by: Tom Watt <tom@buildkite.com>
Signed-off-by: Tom Watt <tom@buildkite.com>
… being used Signed-off-by: Tom Watt <tom@buildkite.com>
Signed-off-by: Tom Watt <tom@buildkite.com>
…nd cache-to parameters
Signed-off-by: Tom Watt <tom@buildkite.com>
Per Issue: #457
To be able to fully support using the
cache-to
parameter, the Build Driver needs to be changed to use a different driver other than the defaultdocker
driver.This PR will add the basic ability to change the driver used in a per Job basis and clean up the Build Instance afterwards to avoid issues of lingering Build Instances.