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
{{ message }}
This repository was archived by the owner on Nov 30, 2023. It is now read-only.
When creating containers, one of the common things to do is to create folders that will be mounted to avoid extension re-installs. The problem is that this really requires creating the folders in the Dockerfile (and potentially the non-root user), which must occur before the common script is run as part of the "feature" call.
Now, clearly, it's possible to download (and run) the common setup script during the dockerfile run, meaning that at least the user is created properly... but that then removes the benefit of the feature section entirely. It would be nice if, instead, there was a list of folder (paths) that the script would create and chown/chmod as appropriate.
The specifically is a request to not to provide a setting for the extension/vscode directories because:
Those paths may change, or the script may be used with something other than vscode
Given the lifecycle of mounted directories/volumes, this enables additional directories to also be setup correctly for mounts.
For the latter point, mounted directories where the target does not already exist are created with root permissions, which causes havoc with extension install, and possibly other cases as well. Too, there is no lifecycle command available in the devcontainer.json format that executes after container creation but before volume mounting, so creating these directories via a loaded setup script is not viable - the directories have already been mounted/created, and the script executes "too late".
The text was updated successfully, but these errors were encountered:
I think these folders can be created as part of the Dockerfile or with a feature script. They are not needed by other feature scripts. (So the existing common script should not be affected.)
@bamurtaugh@chrmarti Yeah this sounds a bit more like a devcontainer spec request. There's nothing in the contents of this repository that could do this on its own.
... I think I'm actually going to close without creating an issue there:
One reason for this is to deal with user/uid mismatches with bind mounts, but they're already tracking a docker issue that allows specifying permissions/owners for bind mounts, which renders that part of the request moot.
The other is primarily for creating folders inside the user directory before mounting. One of the issues in the spec repo brought up modifying the /etc/skel directory, which turns out to be way cleaner.
Possibly an issue should be raised here if having vscode cache extensions on its own, external from the spec is desired.
Relates to: Both
When creating containers, one of the common things to do is to create folders that will be mounted to avoid extension re-installs. The problem is that this really requires creating the folders in the
Dockerfile
(and potentially the non-root user), which must occur before the common script is run as part of the "feature" call.Now, clearly, it's possible to download (and run) the common setup script during the dockerfile run, meaning that at least the user is created properly... but that then removes the benefit of the feature section entirely. It would be nice if, instead, there was a list of folder (paths) that the script would create and
chown
/chmod
as appropriate.The specifically is a request to not to provide a setting for the extension/vscode directories because:
For the latter point, mounted directories where the target does not already exist are created with root permissions, which causes havoc with extension install, and possibly other cases as well. Too, there is no lifecycle command available in the
devcontainer.json
format that executes after container creation but before volume mounting, so creating these directories via a loaded setup script is not viable - the directories have already been mounted/created, and the script executes "too late".The text was updated successfully, but these errors were encountered: