Add option to use volume to avoid reinstalling extensions, VS Code Server on container rebuild

[Chuxel]

By default, VS Code will install extensions and VS Code Server inside the container's filesystem. While this has performance benefits over a locally mounted filesystem, the disadvantage is that VS Code will have to re-install them on a container rebuild. Further, extensions like C#, C++, and Live Share download secondary dependencies after extension install that are also re-downloaded. All of this leads to a slower time-to-start.

We've documented how this can be resolved using a volume mount here: https://code.visualstudio.com/docs/remote/containers-advanced#_avoiding-extension-reinstalls-on-container-rebuild

We can provide an option to do this on the user's behalf to improve discoverability. However, we may not want to enable this by default since it also means that deleting the container would leave the associated volume in place -- which would not be something people would generally expect and could leave the impression that VS Code is leaving behind "junk".

[tomasaschan]

I'd like to add to this suggestion, that it would be nice to "force" installation (and un-installation?) of extensions to match the list in devcontainer.json.

A use case:

I set up a repository for working in a dev container, configures it to install a few extensions and happily go on with coding for a while. I then invite another collaborator, who knows of an extension that provides good stuff that I didn't know about. They add it to the list, but I need to manually find it in the marketplace and install it; the only way to install it "from the list" is to purge my volume and start over with all extensions.

I'm sure you could come up with a bunch of other situations, too, where an extension would be added to the list after the volume had been created, and it would be nice for the user to be able to "apply the list".

Another nice-to-have would be to take the list of currently installed extensions, and update the list to match. In other words, take whatever extensions I have now, no matter why they were installed, and commit the list to devcontainer.json so that my colleague can get the same list without me having to manually go through and make sure the lists match.

[chrmarti]

Some ideas:

1. Use the new "mounts" property.
2. Let the user just pick a volume name, e.g.: "extensionVolume": "myextensions"
3. Automatically pick a volume name, e.g.: "useExtensionVolume": true
4. Use a vscode volume shared among containers with separate folders per container.

We need to be careful not to mislead the user towards sharing the same extension location between containers because that invalidates assumptions about exclusive access in the extension management. (/cc @sandy081 to confirm)

Using a shared volume has the appeal of avoiding the same number of volumes as dev containers, but it requires a strategy for deleting obsolete folders.

[rubensa]

This is my current work-flow:

• On first run I share and empty ${localWorkspaceFolder}/.vscode-server volume (this "forces" server bin and extensions to be installed):

...
"runArgs": [
// $(id -u):$(id -g)
"-u", "1000:1000",
// Container username is "user" (not "root")
"-v", "${localWorkspaceFolder}/.vscode-server:/home/user/.vscode-server"
]
...

• Then I delete data folder inside shared ${localWorkspaceFolder}/.vscode-server.vscode-server and rebuild sharing only bin and extensions subfolders:

...
"runArgs": [
// $(id -u):$(id -g)
"-u", "1000:1000",
// Container username is "user" (not "root")
"-v", "${localWorkspaceFolder}/.vscode-server/bin:/home/user/.vscode-server/bin",
"-v", "${localWorkspaceFolder}/.vscode-server/extensions:/home/user/.vscode-server/extensions"
]
...

This way subsequent builds run postCreateCommand (as data folder with it's markers is not keept) but extensions are cached.

If I want to "re-evaluate" devcontainer.json extensions, I delete ${localWorkspaceFolder}/.vscode-server/extensions folder and rebuild sharing ${localWorkspaceFolder}/.vscode-server (like first time build).

It would be "great" to have a "maker" to say if I want to (re-)evaluate devcontainer.json extensions (despite .vscode-server/extensions folder existence).

More on this, It wold be "great" If I could specify If I want to install or not non existing extensions and remove or keep not defined extensions on devcontainer.json.

Could this be done with a new property "cache" on devcontainer.json?

"cache": {
"vscode-server.extensions": keep|override|add_new|remove_old
}

[chrmarti]

@rubensa I agree on the marker file, that would also allow you to skip the initial startup where you share the entire .vscode-server folder - if I understand correctly.

Having an option to control if / how extensions are updated also makes sense. Could you open a separate feature request for that?

We need to think more about having a shared volume (like a vscode volume) where we hold server and extension installs to improve startup performance. (E.g., updates need to be coordinated, obsolete installs need to be removed.)

[rubensa]

@rubensa I agree on the marker file, that would also allow you to skip the initial startup where you share the entire .vscode-server folder - if I understand correctly.

Yes, @chrmarti that's the point. Despite the existence or not of the extensions folder, if the marker file does not exists and the folder is empty, the extensions should be installed.

Having an option to control if / how extensions are updated also makes sense. Could you open a separate feature request for that?

Done #1920

[chrmarti]

Added a marker file, so the extensions folder can be mounted directly.

Future investigations could include a single volume holding extensions and server installs to speed up provisioning.