Right now, if a compose file references an undefined environment variable, docker-compose
prints a warning and defaults it's value to an empty string, as described here.
This may not always be the desired approach and can mask a failure in continuous deployment environment.
I think there are 2 backward compatible ways to address this:
docker-compose config --strict
${VARIABLE?err_msg}
and ${VARIABLE:?err_msg}
substitution syntax.+1, but why does there need to be customizable error messages? What's wrong with "VARIABLE is undefined"?
@washtubs there does not need to be a customizable error message, but if 2nd option is chosen then it is consistent with the existing syntax for defaults and allows to have a custom error message.
Wouldn't this be better handled by the application/service itself? The same container could also be started outside of compose, in which case it would also have to deal with the missing environment variables
@thaJeztah
Wouldn't this be better handled by the application/service itself?
A variable is not necessarily passed to the application. For example a variable can be a name of an image or a tag.
I've got a potential implementation in #5531 - let me know what you think!
Docs for this were added in https://github.com/docker/docker.github.io/pull/5826
Thanks for implementing this, having the option to fail fast in this case is very useful.
Most helpful comment
Docs for this were added in https://github.com/docker/docker.github.io/pull/5826