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
We have many devcontainers for many different projects, and these projects use environment variables to access secrets.
Our current strategy to manage this is having all the secrets for all the projects set in Windows, with the variables listed in WSLENV, and then we use remoteEnv in the devcontainer.json files to make the appropriate subset of variables available inside each devcontainer.
To tidy this up, I wanted to store the secrets in 1Password, store references to them in a .env file in each repository, and then use the 1Password CLI to launch the devcontainer using the appropriate .env file.
The way this works is that the .env file for each repo contains entries like:
And you launch VSCode with the 1Password CLI like so:
op run --env-file .env -- code .
The 1Password CLI parses the .env file, resolves the references, and launches VSCode with those resolved variables set in the process' environment.
The above works perfectly when running VSCode in Windows and in Remote: WSL, but I can't seem to get the environment variables to pass through into a devcontainer.
To launch the devcontainer I am doing the following:
This uses one of the solutions from here to launch VSCode directly into a devcontainer, with op run inserted at the appropriate point to launch VSCode. However, currently the dev container doesn't seem to get its environment from the process that launched it.
The simple test of this is just to export FOO=BAR in a shell and then try and launch a VSCode devcontainer from the same shell and have that local FOO envionment variable available in the devcontainer.
Would it be possible to support this scenario?
The text was updated successfully, but these errors were encountered:
Hey, I'm running into the same issue on Windows and WSL2, while others on the team on Linux and OS-X have exactly the same use-case working just fine (op run --env-file=... code into devcontainer).
The work around we came up with was to use WSLENV https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/
its been working well so far.
Basically I put the following in my devcontainer.json:
// Use the 1Password CLI to generate a .env.tmp file with secrets.
"initializeCommand": "op inject --force --in-file .env --out-file .env.tmp",
// Load the env file generated by the 1Password CLI.
"runArgs": [
"--env-file",
".env.tmp"
],
// Clean up env file generated by the 1Password CLI.
"postStartCommand": "rm .env.tmp",
The issue above is a request to support unix pipes in the dev container's runArgs, which would eliminate the need for a temp file. Please upvote the issue if you feel it would help you as well.
We have many devcontainers for many different projects, and these projects use environment variables to access secrets.
Our current strategy to manage this is having all the secrets for all the projects set in Windows, with the variables listed in WSLENV, and then we use
remoteEnv
in thedevcontainer.json
files to make the appropriate subset of variables available inside each devcontainer.To tidy this up, I wanted to store the secrets in 1Password, store references to them in a
.env
file in each repository, and then use the 1Password CLI to launch the devcontainer using the appropriate.env
file.The way this works is that the
.env
file for each repo contains entries like:And you launch VSCode with the 1Password CLI like so:
The 1Password CLI parses the
.env
file, resolves the references, and launches VSCode with those resolved variables set in the process' environment.The above works perfectly when running VSCode in Windows and in Remote: WSL, but I can't seem to get the environment variables to pass through into a devcontainer.
To launch the devcontainer I am doing the following:
This uses one of the solutions from here to launch VSCode directly into a devcontainer, with
op run
inserted at the appropriate point to launch VSCode. However, currently the dev container doesn't seem to get its environment from the process that launched it.The simple test of this is just to
export FOO=BAR
in a shell and then try and launch a VSCode devcontainer from the same shell and have that localFOO
envionment variable available in the devcontainer.Would it be possible to support this scenario?
The text was updated successfully, but these errors were encountered: