You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 3, 2022. It is now read-only.
-d, --driver string Specify a driver name (default "docker")
This means that even if a bundle supports only one invocation image, then if that image happens to be a non-Docker one then the user must specify the driver.
Where only one driver is possible, we should default the driver name to that. If multiple drivers are compatible with the bundle, we might consider requiring the user to specify which one they want rather than always defaulting to Docker.
(It is also very unclear to me how we discover what drivers are available and what drivers are suitable for any given bundle or invocation image. If we plan to mention drivers in the CLI interface, then we need ways for tooling to interact with them programmatically even if we actually have no drivers other than Docker on day one - otherwise tooling will fail once a second driver is introduced.)
The text was updated successfully, but these errors were encountered:
Specifically, can I use the set of imageTypes in invocationImages as a driver prompt, or do I need to allow for the possibility that there might be multiple drivers targeting the same imageType. It's hard to know because the only imageType that seems to do anything right now is docker and I don't know whether the fact that the only driver is also docker is a coincidence or a Giant Clue.
Currently, drivers are discovered "lazily" by looking for a driver when --driver is specified, and then running it to make sure that it supports the type.
For example, say the image type is qux. And say that the user runs the command:
Duffle will execute the duffle-bananarama --handles command to see if the image type qux is in its list. If it is, then the driver will be executed. If not, Duffle will produce an error.
If we want to support the requested behavior, we'll have to get a little more sophisticated about how we do our drivers.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
duffle install
docs currently state:This means that even if a bundle supports only one invocation image, then if that image happens to be a non-Docker one then the user must specify the driver.
Where only one driver is possible, we should default the driver name to that. If multiple drivers are compatible with the bundle, we might consider requiring the user to specify which one they want rather than always defaulting to Docker.
(It is also very unclear to me how we discover what drivers are available and what drivers are suitable for any given bundle or invocation image. If we plan to mention drivers in the CLI interface, then we need ways for tooling to interact with them programmatically even if we actually have no drivers other than Docker on day one - otherwise tooling will fail once a second driver is introduced.)
The text was updated successfully, but these errors were encountered: