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
docker-compose lets you specify an env_file to decouple variables from the main configuration. Would be handy to let Garden do the same and make it easier for users migrating from docker-compose to adopt.
The text was updated successfully, but these errors were encountered:
That's a good idea. One thing I'm wondering: Would we merge the variables from the file with the other variables under ${local.env.<key>} or have a separate key? I could lean either way tbh.
Perhaps we could merge by default, and optionally allow users to specify a different key? When merging under local.env, in case of duplicate keys, I feel variables set in a service's config should override those set in the env file.
I'd like to avoid multiple layers of optionality if possible. Also, variables set in a service's config have nothing to do with the local.env key, doesn't flow in that direction, so there's nothing to consider there really.
So it's only a question of whether we merge env files into local.env or make e.g. a separate local.env-file (or even just env-file) template key. I'm sorta leaning towards the former but still not decided.
docker-compose lets you specify an env_file to decouple variables from the main configuration. Would be handy to let Garden do the same and make it easier for users migrating from docker-compose to adopt.
The text was updated successfully, but these errors were encountered: