Launch.json envFile Won't Override Dev Container Env

[stnguyen90]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • go version go1.14.6 linux/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
  • 1.47.2
    • 17299e413d5590b14ab0340ea477cdd86ff13daf
    • x64
• Check your installed extensions to get the version of the VS Code Go extension
  • 0.15.2
• Run go env to get the go development environment details

GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vscode/.cache/go-build"
GOENV="/home/vscode/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/workspaces/vscode-remote-try-go/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build951096275=/tmp/go-build -gno-record-gcc-switches"

Share the Go related settings you have added/edited

{
    "go.useLanguageServer": true,
    "go.inferGopath": false
}

Describe the bug

Specifying an envFile in a launch config doesn't seem to work.

Steps to reproduce the behavior:

1. Open https://github.com/stnguyen90/vscode-remote-try-go/tree/launch-with-env-file in a dev container
2. Run "Launch without any overrides"
3. See Testing: devcontainer
4. Run "Launch with envFile override"
5. See Testing: devcontainer

Expected output is Testing: env file

Overriding using env rather than envFile seems to work.

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.

[hyangah]

@stnguyen90 thanks for the bug report.

The debug adapter constructs the environment variables by merging process.env, env vars read from launchArgs.envFile, and then launchArgs.env in order. it looks like when running in devcontainer, launchArgs.env contains the environment variables set as containerEnv in devcontainer.json.

launchArgs.env: {
  "GOPATH":"/go",
  "HOSTNAME":"04dc1073bc36",
  "HOME":"/home/vscode",
  "TESTING":"devcontainer",
  "GO111MODULE":"auto",
  "REMOTE_CONTAINERS_IPC":"<tmp sock file>",
   "PATH":"/usr/local/go/bin:/home/vscode/.vscode-server/bin/91899dcef7b8110878ea59626991a18c8a6a1b3e/bin:/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
...
}

launchArgs.env takes precedence over launchArgs.envFile. I don't know much about dev container internal.

@Chuxel can you help us understand why devcontainer has to add these extra envs again in the launch args and what's the best practice in handling env variables? Thanks!

[stnguyen90]

Could this be what's setting the launchArgs.env to the container environment?

https://github.com/golang/vscode-go/blob/38b056d2536082e93b8663763b0e5509cacc2560/src/goDebugConfiguration.ts

I tried to find where Delve was initialized to try and see how launchArgs was initialized but this was the best I could find.

[hyangah]

@stnguyen90 You are right - i forgot we mutate launchargs env vars there too. Not sure why it needs to mutate the launch env arg. If it is necessary it needs to process the launch args as the debug adapter does. :-(

[Chuxel]

@Chuxel can you help us understand why devcontainer has to add these extra envs again in the launch args and what's the best practice in handling env variables? Thanks!

Variables set using containerEnv should be the equivalent of passing -e into Docker, so I'd expect that to actually be in process.env. @chrmarti - Any ideas here?

[chrmarti]

I think only docker-compose automatically picks up a .env file in its working directory. docker run doesn't do that. You can use "runArgs": ["--env-file", "./env"] in the devcontainer.json instead.

[stnguyen90]

Any environment file in devcontainer.json only applies for when the container is first spun up. The launch configs I'm referring to are important for overriding environment variables for any particular launch/debug session after the dev container has already started.

[chrmarti]

Since "env" works, I'd expect "envFile" to also work unless there is a bug in the implementation of "envFile" itself. I don't think this is a problem with Remote-Containers.

[stnguyen90]

Since "env" works, I'd expect "envFile" to also work unless there is a bug in the implementation of "envFile" itself. I don't think this is a problem with Remote-Containers.

Tested:

1. Set TESTING env variable of host to "os"
2. Run "Launch without any overrides"
3. See Testing: os
4. Run "Launch with envFile override"
5. See Testing: os
6. Run "Launch with env overrides container env"
7. See Testing: env

So, yes, you are correct. Remote Containers are just a red herring. The OS env vars overrides envFile with and without remote containers.

I still think this might be the problem:

vscode-go/src/goDebugConfiguration.ts

Lines 65 to 70 in 38b056d

	const goToolsEnvVars = toolExecutionEnvironment();
	Object.keys(goToolsEnvVars).forEach((key) => {
	if (!debugConfiguration['env'].hasOwnProperty(key)) {
	debugConfiguration['env'][key] = goToolsEnvVars[key];
	}
	});

. I'm just not sure what the best way to solve the problem is.

[stnguyen90]

Would it be okay to remove goToolsEnvVars from debugConfiguration['env']?

[gopherbot]

Change https://golang.org/cl/248659 mentions this issue: src/goDebugConfiguration: combine envFile and env