Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container env vars not updated by features while setting up #1354

Open
Benjamin-Etheredge opened this issue Nov 3, 2024 · 1 comment
Open
Labels

Comments

@Benjamin-Etheredge
Copy link

What happened?
When using base devcontainers and features to install additional tooling, the environment variables set by the features are not correctly set for other features and commands. If a feature defines a new containerEnv, it will work. But if it extends an existing environment variable, it is not updated.
I suspect this breaks a TON of features if one depends on another.

What did you expect to happen instead?
Environment variable adjustment from features to work for other features and commands

How can we reproduce the bug? (as minimally and precisely as possible)

My devcontainer.json:

{
	"image": "mcr.microsoft.com/devcontainers/base:noble",
	"features": {
		"ghcr.io/devcontainers/features/python:1": {},
		"ghcr.io/devcontainers/features/rust:1": {}
	},
	"postStartCommand": "env"
}

The following will show PYTHON_PATH and other variables set by the feature show up correctly, but PATH is not updated to the correct version for subsequent features or commands. At the start of features, it shows the correct values, but in the features, the path is incorrect as shown by the rust feature printing out PATH during setup.

Local Environment:

  • DevPod Version: v0.5.21
  • Operating System: windows
  • ARCH of the OS: AMD64

DevPod Provider:

  • Local/remote provider: docker

Anything else we need to know?
The variables are set correctly in the terminal after starting the devcontainer. The issue is only present during feature setup and commands like postCreateCommand.

@bkneis
Copy link
Contributor

bkneis commented Nov 14, 2024

Thanks @Benjamin-Etheredge for reporting this issue! I can confirm the problematic behaviour, I'll try get around to fixing this soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants