Skip to content

Use ENV instead of ARG for USERNAME#35

Open
alza-bitz wants to merge 1 commit intoscicloj:mainfrom
alza-bitz:fix-error-cloning-repo-in-container-volume
Open

Use ENV instead of ARG for USERNAME#35
alza-bitz wants to merge 1 commit intoscicloj:mainfrom
alza-bitz:fix-error-cloning-repo-in-container-volume

Conversation

@alza-bitz
Copy link
Copy Markdown
Contributor

To persist the value into running containers.

Fixes #29.

To persist the value into running containers.

Fixes scicloj#29.
@behrica
Copy link
Copy Markdown
Member

behrica commented Mar 7, 2025

I still now too little about this.
When we use ARG, we loose the capability to have it overwritten with the host variable, correct ?

alza-bitz added a commit to alza-bitz/playpen-clojure that referenced this pull request May 15, 2025
alza-bitz added a commit to alza-bitz/alza-bitz.github.io that referenced this pull request May 27, 2025
@alza-bitz
Copy link
Copy Markdown
Contributor Author

I still now too little about this. When we use ARG, we loose the capability to have it overwritten with the host variable, correct ?

Hi @behrica apologies for the delayed reply.

I don't know what you mean by "host variable"? Is there any use case or scenario where the username in the container needs to be something other than "vscode"?

Regarding ARG vs ENV, this article explains the difference:

https://www.docker.com/blog/docker-best-practices-using-arg-and-env-in-your-dockerfiles/

ARG: "The ARG instruction allows you to define variables that will be accessible during the build stage but not available after the image is built."

ENV: "Unlike ARG, the ENV command allows you to define a variable that can be accessed both at build time and run time."

This would imply that changing from ARG to ENV will not break anything, since ENV is available in both contexts.

It also implies that USERNAME is needed at run time when the container starts. However, without further investigation I can't explain why (build-time only) ARG is sufficient for the "new dev container" case but not sufficient for the "clone repository in container volume" case.

Suggestion: if ENV is observed to work for USERNAME in both cases anyway, that is a sufficient test result, and so this PR could be merged?

Btw, some context:

  1. I raised this issue because I am hitting it every time I use "clone repository in container volume". Each time, I have to manually edit the Dockerfile in a recovery container, then rebuild again.

  2. AFAIK this template is the only Clojure template available inside the VSCode menus (thanks to your efforts!) but as such, if it doesn't work then there's no alternative available (other than manually fixing the issue each time, or rolling your own template).

@behrica
Copy link
Copy Markdown
Member

behrica commented Sep 21, 2025

I don't know what you mean by "host variable"? Is there any use case or scenario where the username in the container needs to be something other than "vscode"?

In some scenarios I have used devcontainer with other usernames, like my real username on the host.
This affects "permissions" between host and container.

I am not sure, if this needs to be supported by a devcontainer.
vscode / devcontainer-cli does quite some "magic" to fix permissions between host and container

@behrica
Copy link
Copy Markdown
Member

behrica commented Sep 21, 2025

so I am not sure, if this PR fixes a still existing problem. (and if it is the right way to solve)

@alza-bitz

Could you please describe again in #35 "your scenario" and the "issue you have" with the latest template version (if still present)

@alza-bitz
Copy link
Copy Markdown
Contributor Author

alza-bitz commented Dec 2, 2025

so I am not sure, if this PR fixes a still existing problem. (and if it is the right way to solve)

@alza-bitz

Could you please describe again in #35 "your scenario" and the "issue you have" with the latest template version (if still present)

Hi @behrica, apologies for the delayed reply.

I hit this problem again yesterday so I will describe again here the steps to reproduce, the expected result and the actual result:

Steps:

  1. In VSCode, choose "dev containers: clone repository in container volume"
  2. When prompted for the repo to clone, select the project repo from Github. The conditions are that it can be any deps.edn Clojure project that doesn't already have a .devcontainer/devcontainer.json. In my case I chose https://github.com/cse-bristol/clj-lp but as I say, it can be any project as long as it meets the conditions.
  3. When prompted for a devcontainer template, select the basecloj template. I just type "clojure" and the basecloj template is shown in the results

Expected:

Project is cloned successfully and basecloj container starts successfully with no errors. Calva extension is available and works, clj command is available and works.

Actual:

Container doesn't start successfully, instead it fails with an error message due to USERNAME not being populated. The RUN groupadd ... command from the Dockerfile fails when USERNAME does not get picked up.

Instead, I have to then

  • "Edit Dockerfile in recovery container"
  • Change the Dockerfile from ARG USERNAME=vscode to ENV USERNAME=vscode (same as the fix in this PR)
  • Restart the container with these changes.

Then, the container is able to start successfully.

As you can imagine, it's frustrating that this error is being hit every time a developer needs to work on a different project locally. This error will block anyone trying to develop on any Clojure project from GitHub that doesn't already have a .devcontainer/devcontainer.json present (and includes the ENV USERNAME fix), so the impact is quite extensive.

By comparison, the equivalent "dev containers: clone repository in container volume" built-in use-case and same steps for projects in other languages works fine. So it seems reasonable that we should expect this scenario to work for Clojure projects.

I hope this makes sense now?

Thanks

Alex.

@behrica
Copy link
Copy Markdown
Member

behrica commented Dec 2, 2025

I never use 'dev containers: clone repository in container volume', so that's why I don't see the error.

I always do "git clone ..." and open the folder

@behrica
Copy link
Copy Markdown
Member

behrica commented Dec 2, 2025

I executed the steps sas you said above, but dont get any error.
Which host OS are you using ?

@alza-bitz
Copy link
Copy Markdown
Contributor Author

Hi @behrica apologies for the delayed reply, I found some time to look at this again in more detail.

The host OS where I see the error is Windows. I believe this is the problematic line in devcontainer.json:

"USERNAME": "${localEnv:USER:vscode}"

I believe there are two issues:

  1. The ${localEnv:VAR} syntax is referring to environment variables on the host, according to the dev container docs. However, while USER exists on some operating systems, on Windows it is instead USERNAME and so the lookup will fail in those cases.

  2. The ${localEnv:VAR:default} syntax should use "default" as a fallback when the host environment variable is missing, according to the dev container docs. However, my experiments revealed that this feature is not working, at least on Windows when combined with the localEnv syntax.

So as a result, on Windows hosts USERNAME will be empty when the Docker build runs and the groupadd command in the Dockerfile will fail.

My suggested fix would be to hard-code the user name ("vscode" for example) in all the relevant places, devcontainer.json and Dockerfile.

It would lose the matching user name for new containers, but I hope that wouldn't be a problem?

If you're agreeable, I'd be happy to close this PR and make a new one. It would prevent the error for anyone who is trying to use the template from Windows.

Thanks 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Error when cloning repo in container volume using basecloj template

2 participants