-
Notifications
You must be signed in to change notification settings - Fork 54
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
Make it easier to pass additional volume bindings into run.sh #675
Comments
Something like ODK_BINDS=<host-directory>:<mounting-point>,<host-directory>:<mounting-point> sh run.sh make ... ? |
since I think most volume binding efforts are more permanent, I was thinking of adding this to the config file:
And the manifest the bindings with Jinja. That way the |
This would make the behaviour dependent on absolute directories from one editor’s machine (the editor who manages the config file and runs the |
Very good point.. No. I guess not. But you could add recommendation for PWD syntax?
|
If it’s expected that the most common use case will be to bind directories located somewhere in the repository, we could make that the default? That is, allow things like
and treat Conversely, if the specified directory is absolute ( |
The more you ask about the less clear it is to me how advantages it is to make it configurable. My current use case is a binding outside the repo, but its so edge case.. Also cross-platform wont work with the config file approach. Maybe a generic |
The (slight) advantage of a variable specifically intended for bindings (
But maybe it’s not worth the added complexity, and it’s fine to require users wanting an extra binding to know enough about Docker to know which option to use. |
Random crazy idea: for users who find themselves regularly having to pass options to That file would not be committed (it could be added to the exclusion list in |
I think this is a great idea.. would make docker options in ODK redundant! |
This way, we do not need to hack run.sh when we need to, for example, bind config files to tools which are not located in the working directory.
The text was updated successfully, but these errors were encountered: