Vscode-remote-release: Add envFile to devcontainer.json and handle missing env file gracefully

[njbmartin]

I'm using "runArgs": ["--env-file","devcontainer.env"] to spin up the container with some environment variables. This devcontainer.env file isn't committed, so when the repo is cloned for the first time, it doesn't exist. This results in a hard failure.

It would be great if you could specify this via an envFile in the container config, and if the file doesn't exist, it warns you instead of resulting in a hard failure.

[PavelSosin-320]

I vote for it!. Also service configs to pass such content as local Docker repositories URL's, Local gerrit URls, etc.

[erlloyd]

I just ran into this same problem, and I would also love if this gave a warning as opposed to a hard failure!

[Chuxel]

1.46 adds the ability to go into a recovery container where you can add files and then rebuild the container much like you can when using the local filesystem.

[erlloyd]

@Chuxel So does it automatically go into a recovery container any time it encounters an error? That's pretty cool - but I still see the need for a warning / graceful handling of no env file. For example, I have a repo where a developer can still do most things without needing the env variable. So it's annoying to tell developers that don't need the env variable that they still have to create an empty .env file

[Chuxel]

Yeah, re-reading, I jumped to the assumption that this was a "open repository in container" scenario (due to so when the repo is cloned). To clarify, the new feature in 1.46 is that, when the error appears, there is a button in the error dialog for "open repository in container" flow to "open in recovery container". The flow is much like clicking on "Reopen Locally" to fix errors when opening a folder from the local filesystem. In open repository case, it just uses a simple container with Git and a few other things in it to connect to the volume with the source code.

In terms of filtering out the env file if it's missing, I don't know that we can do that for Docker Compose since that's a Docker format and tool. We could add it as a property for other scenarios, but out of curiosity, why does the repo not contain a env file with the expected defaults for developers (at least as a template)?

[erlloyd]

Good question! In my particular case it has to do with AWS credentials. Some of the tasks a developer may perform include needing to access our AWS environment (uploading files to s3, for example, as part of a deploy to a temporary environment). However, the AWS creds are _not_ necessary for every developer. In fact, most developers can run the app and do all of their daily work without needing to worry at all about AWS creds.

Obviously, I'm not opposed to a template .env file, and if a .env file is required it's easy enough to tell devs to just create an empty file. But it just seems like a step I shouldn't have to tell all developers.

docker-compose already supports this (kind of) because in the docker-compose.yml file, if you reference a host environment variable, docker-compose will look for a .env file in the same directory and use values in it if it is present, but fall back to just looking at host variables if the file isn't present.

So it's also interesting you mention "open repository in container" because the whole reason I went away from using docker-compose.yml files with my .devcontainer configuration is because "open repository in container" doesn't work with docker-compose! But then I encountered this issue, where even with a normal clone-to-host workflow (not "open repository in container") forced me to require a .env file.

There's also a chance there's just a bug that needs to be fixed. The VSCode remote containers documentation indicates that a .env file in the project root _should_ just be picked up:

VS Code will automatically pick up a file called .env in your workspace root, but you can also create one in another location.

That never worked for me.

Ok, sorry for all the information, but hopefully that helps give some context!

[ascheucher]

I consider a soft fail on a missing .env file as problematic.
It's much easier to do a touch .devcontainer/.env than to search for hours why your software is not behaving as expected. Especially as a new team member.
When it's failing you know some configuration is expected here.