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
Hi,
Great project!
I have been hacking on something similar some time ago (not available for the public).
One requirement I have is being able to to pass environment variables into the docker container, which is the recommended way to configure containers at runtime. E.g for me nut test fails because wget does not know about my http proxy. E.g. passing my HTTP_PROXY env variable to the docker container would help.
A generic solution to this would be to support docker-compose files. There is a library for golang https://github.com/docker/libcompose for docker-compose.
The rationale would be that a lot of people already might have docker-compose files at least for services (start a Jboss server). docker-compose also has support for reusing stopped containers (only works if your run the exact same command).
The text was updated successfully, but these errors were encountered:
Yes, we need env variables. The plan is to be able to specify them in the nut.yml, along with any other parameters that we can give to docker cli (directories, ports binding, env variables, etc).
In addition to this I like the idea of supporting compose files, especially since you mention the lib in Go and the ease of use for compose users. And the two options could work together by introducing a new kind of base environment in nut.yml:
based_on:
compose:
path: path/to/docker-compose.ymlservice: reddis # I don't think it would make sense to inherite configuration from several services, right?
Hi,
Great project!
I have been hacking on something similar some time ago (not available for the public).
One requirement I have is being able to to pass environment variables into the docker container, which is the recommended way to configure containers at runtime. E.g for me nut test fails because wget does not know about my http proxy. E.g. passing my HTTP_PROXY env variable to the docker container would help.
A generic solution to this would be to support docker-compose files. There is a library for golang
https://github.com/docker/libcompose for docker-compose.
The rationale would be that a lot of people already might have docker-compose files at least for services (start a Jboss server). docker-compose also has support for reusing stopped containers (only works if your run the exact same command).
The text was updated successfully, but these errors were encountered: