vscode server extensions in volume

[qmacro]

trafficstars

During this phase of the project, I'm rebuilding the Docker image and also creating new containers even more often. Each time VS Code is attached to a (new) running container, it installs extensions into it (in a $HOME/.vscode-server/extensions/ directory). This takes time and is wasteful.

Following the instructions at Avoiding VS Code extension reinstalls I have come up with a temporary (and non-intrusive) way of avoiding this time.

The idea is that I have a named volume which is mounted to the container at $HOME/.vscode-server/extensions/ and for the first time, extensions that are installed remotely into the container with that volume mounted will end up inside that volume. While the container lifetime is short, the volume lifetime is longer and the extensions will live on, to be remounted to a new container when appropriate.

In order to (a) not modify the ./run script(s), and (b) ensure that I have a named volume and that it's mounted to the containers, I have created a docker-compose.yaml file in config/, and also added a RUN command in the Dockerfile itself to create the $HOME/.vscode-server/extensions/ directory that can then be the mount point for the volume (this is created anyway by VS Code when it first attaches, if it doesn't exist already).

From within the root of the repo, my flow is:

1. ./run: Build the image (this will also cause a new container to be started from the newly built image)
2. docker stop btp-setup-automator: Stop the new container (it will be auto-removed as it's started with --rm by ./run)
3. docker compose -f config/docker-compose.yaml up -d: Start a new container and mount the named volume as described above

Then I can go into VS Code and attach to that running container as normal. And the next time (I build the image or) start a new container -- as long as I use the docker compose command which will attach the volume -- the VS Code attach process will run much quicker.

[qmacro]

I've added an environment section to the compose definition, so now the BTPSA_VERSION_GIT environment variable, that is constructed and passed into the container when it's started from within the run script, can now also be supplied in this new approach, like this:

BTPSA_VERSION_GIT=$(git describe --long --tags --always) \
  docker compose -f config/docker-compose.yaml up -d

(Unfortunately the compose file syntax does not support command substitution, which is why we have to do it like this).

[lechnerc77]

Hi @qmacro ,

maybe of interest for this draft PR: we added devcontainer functionality to the repository. With this you can start a devcontainer based on the provided container images from the dev or main branch. The local data is then available in the directory /workspaces that you can access from within the container. Does this solve the main issue you are addressing in this PR?

Best, Christian

[qmacro]

Closing as per discussion with @lechnerc77