Feature envvars and action `env:` options aren't passed to `docker run`

[trxcllnt]

It seems like envvars added by features and via the action's env: option aren't passed to docker run. VSCode does pass them to docker run. This is important for shell init scripts that expect the envvars to exist when the container is started.

Example of VSCode's behavior:

docker run --sig-proxy=false -a STDOUT -a STDERR \
  `# ...` \
  -e LANG=en_US.UTF-8 \
  -e NVIDIA_DISABLE_REQUIRE=true \
  -e CC=gcc \
  -e CXX=g++ \
  -e CUDAHOSTCXX=g++ \
  -e PYTHON_VERSION=3.13 \
  --entrypoint /bin/sh vsc-devcontainers-954e198c667c39268cc299cf82b04e5e1818c554baccfa2555269604372fc153-uid \
  -c echo Container started

devcontainers/ci behavior:

docker run --sig-proxy=false -a STDOUT -a STDERR \
  `# ...` \
  -e LANG=en_US.UTF-8 \
  -e NVIDIA_DISABLE_REQUIRE=true \
  -e PYTHON_VERSION=3.13 \
  --entrypoint /bin/sh vsc-devcontainers-4ec525fa91aa7d1bf05e336d30063cc11430f50413ea10c3c0d37f8fe16cb41b-uid \
  -c echo Container started

Digging into the difference between their devcontainer up commands, I see VSCode isn't using --remote-env anywhere:

devcontainer up \
  --user-data-folder /home/ptaylor/.config/Code/User/globalStorage/ms-vscode-remote.remote-containers/data \
  --container-session-data-folder /tmp/devcontainers-5417b12b-bcd8-4a49-ab65-556b2e796a371751917899255 \
  --workspace-folder /home/ptaylor/dev/rapids/devcontainers \
  --workspace-mount-consistency cached \
  --gpu-availability detect \
  --id-label devcontainer.local_folder=/home/ptaylor/dev/rapids/devcontainers \
  --id-label devcontainer.config_file=/home/ptaylor/dev/rapids/devcontainers/.devcontainer/cuda12.9-pip/devcontainer.json \
  --log-level debug \
  --log-format json \
  --config /home/ptaylor/dev/rapids/devcontainers/.devcontainer/cuda12.9-pip/devcontainer.json \
  --default-user-env-probe loginInteractiveShell \
  --mount type=volume,source=vscode,target=/vscode,external=true \
  --skip-post-create \
  --update-remote-user-uid-default on \
  --mount-workspace-git-root \
  --include-configuration \
  --include-merged-configuration

However the devcontainers/ci action defines all the the envvars with --remote-env:

devcontainer up \
  --workspace-folder /home/runner/_work/devcontainers/devcontainers \
  --remote-env GITHUB_OUTPUT=/mnt/github/output \
  --remote-env GITHUB_ENV=/mnt/github/env \
  --remote-env GITHUB_PATH=/mnt/github/path \
  --remote-env GITHUB_STEP_SUMMARY=/mnt/github/step-summary \
  --config /home/runner/_work/devcontainers/devcontainers/.devcontainer/cuda12.9-conda/devcontainer.json \
  --mount type=bind,source=/home/runner/_work/_temp/_runner_file_commands/set_output_fe6df713-9b89-4697-b75c-89f6f821d7dd,target=/mnt/github/output \
  --mount type=bind,source=/home/runner/_work/_temp/_runner_file_commands/set_env_fe6df713-9b89-4697-b75c-89f6f821d7dd,target=/mnt/github/env \
  --mount type=bind,source=/home/runner/_work/_temp/_runner_file_commands/add_path_fe6df713-9b89-4697-b75c-89f6f821d7dd,target=/mnt/github/path \
  --mount type=bind,source=/home/runner/_work/_temp/_runner_file_commands/step_summary_fe6df713-9b89-4697-b75c-89f6f821d7dd,target=/mnt/github/step-summary

What do --include-configuration and/or --include-merged-configuration do? Would adding them fix this behavior in the devcontainers/ci action?

[Kaniska244]

Hello @trxcllnt ,

Thank you for reporting this issue. Would you kindly share your CI script yml file, devcontainer.json and Dockerfile/ docker-compose.yml to investigate this further.
The env tag in general works fine, they pass on the required key/value pairs as remote env variables which are indeed accessible inside the container.
Below a basic sample CI script:

name: Dev Container CI

on:
  workflow_dispatch:

jobs:
  build-and-run-devcontainer:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Build and Run Dev Container
        uses: devcontainers/ci@v0.3
        with:
          runCmd: |
            echo "MY_ENV_VAR: $MY_ENV_VAR"
            echo "ANOTHER_VAR: $ANOTHER_VAR"
            env  # Lists all environment variables in the container
          env: |
            MY_ENV_VAR=sample-value
            ANOTHER_VAR=42

Also here's the complete log

Kindly let me know if I am missing something here.

With Regards,
Kaniska

[trxcllnt]

@Kaniska244 This line in your logs should have -e MY_ENV_VAR=sample-value -e ANOTHER_VAR=42 to match VSCode behavior.

It should also include the envvars in the "containerEnv": {}" of any features in the "devcontainer.metadata" label of the base image.

[Kaniska244]

Hello @trxcllnt ,

Thank you for the clarification. Let me check this further and get back to you.

With Regards,
Kaniska

[Kaniska244]

Hello @trxcllnt ,

Please find some more details on this. Indeed as I see the implementation of the env tag, it passes on the env vars as --remote-env as part of the devcontainer build, up and exec commands & not as part of containerEnv in the docker run with -e option. However, if we can explicitly specify any env var under containerEnv tag in devcontainer.json, those are indeed passed in docker run command with -e option.
Also another point to be noted here that if as part of any added dev containers feature, some env vars are added using containerEnv in the feature configuration, during the CI build they are indeed persisted as container env vars along with those set in the devcontainer.json as containerEnv but those set with env tag in the CI script aren't available, as you can see in this example, sample basic script here.
We will check further and get back with more details and with possible solution for this if really required.

[djmcgreal-cc]

I couldn't quite follow the above, but I think it boils down to needing a way to set containerEnv? That's my issue anyway, I need to overwrite an environment variable referenced from an postCreateCommand.