Set REMOTE_CONTAINERS=true environment variable

[felipecrs]

This would be good, so scripts can get to know if they're running from a devcontainer on Remote - Containers or not. VS Codespaces have the CODESPACES by the way.

So far, I have to do:

function is_devcontainer() {
  if [ -n "${REMOTE_CONTAINERS_IPC+x}" ] || [ -n "${REMOTE_CONTAINERS_SOCKETS+x}" ] || [ -n "${VSCODE_REMOTE_CONTAINERS_SESSION+x}" ]; then
    return 0
  else
    return 1
  fi
}

Because the referenced variables are not set all the time.

[Chuxel]

Moving this feature request to the correct repo.

[felipecrs]

Oh, my bad.

It does not show up on vscode-dev-containers yet though, should I close this one and create it there?

[Chuxel]

@felipecassiors Nope - I transferred it. The link works from both places when that happens, it's just offically in the vscode-remote-release repo now. 😄

[chrmarti]

@felipecassiors You could add this to your devcontainer.json yourself:

	"remoteEnv": {
		"DEVCONTAINER": "true"
	}

That would cover Remote-Containers and Codespaces. (@Chuxel is there a list of devcontainer.json properties supported by Codespaces?)

[Chuxel]

@chrmarti Yes, this would work fine, but the general request is to have a common way to do it. We could coordinate to get that added. The other one I think may be good to add is LOCAL_WORKSPACE_PATH given that is needed for bind mounting in docker-from-docker. The example does the above to work around that, but it would be reasonable to just have it there.

[felipecrs]

@felipecassiors You could add this to your devcontainer.json yourself:

	"remoteEnv": {
		"DEVCONTAINER": "true"
	}

That would cover Remote-Containers and Codespaces.

I see, but it would just cover the devcontainers I maintain. I need such a variable because of my dotfiles, since I perform some installation steps which are specific for devcontainer or codespaces.

[chrmarti]

Got it. Would it make sense to call it REMOTE_CONTAINERS? Codespaces is running a devcontainer too. We could also make it DEVCONTAINER for both Codespaces and Remote-Containers (and maybe have all 3 to be clear?).

[felipecrs]

Got it. Would it make sense to call it REMOTE_CONTAINERS? Codespaces is running a devcontainer too. We could also make it DEVCONTAINER for both Codespaces and Remote-Containers (and maybe have all 3 to be clear?).

It makes sense, and I believe the best is to have all the 3 as you said. :-)

[chrmarti]

Setting REMOTE_CONTAINERS=true. Please open additional requests for additional variables.

[felipecrs]

@chrmarti thank you so much. So there is no DEVCONTAINER=true as you suggested before?

[chrmarti]

Not right now, we need to coordinate with Codespaces to make sure they introduce that too (going by our earlier discussion). Please open a new issue if you want to see that implemented too.

[felipecrs]

Not right now, we need to coordinate with Codespaces to make sure they introduce that too (going by our earlier discussion). Please open a new issue if you want to see that implemented too.

Alright. It's ok, this already fits my purpose.

[felipecrs]

@chrmarti I just tested here, and the variable does not seem to be set when the dotfiles installation happens. It's only available after. Therefore, I still need to rely on VSCODE_REMOTE_CONTAINERS_SESSION.

Note: CODESPACES is set on GitHub Codespaces during the dotfiles installation.

[chrmarti]

@felipecrs That should be fixed in the latest (0.143.0) could you verify? Thanks.

[felipecrs]

@chrmarti Verified!

I was not able to install v0.143.0 on VSCode stable though, so I installed in the insiders version. Is that expected?

[chrmarti]

@felipecrs Thanks! Yes, that version is only available for VS Code Insiders and then for VS Code 1.50 when that is released.

[felipecrs]

Awesome, thanks.