Support for VS Code Extensions about envbuilder HOT 10 CLOSED

BTW, I currently do this outside the context of envbuilder after the container is built:

 # install and start code-server
  if ! which code-server > /dev/null; then
    curl -fsSL https://code-server.dev/install.sh | sh | tee code-server-install.log
  fi
  CODE_CLI=code-server
  if code; then
    CODE_CLI=code
  fi
  mkdir -p ~/.vscode-server/extensions

  set +e
  extensions=( $(sed 's/\/\/.*$//g' */.devcontainer/devcontainer.json | jq -r -M '[.customizations.vscode.extensions[]?, .extensions[]?] | .[]' ) )
  if [ "$${extensions[0]}" != "" ] && [ "$${extensions[0]}" != "null" ]; then
    for extension in "$${extensions[@]}"; do
      $CODE_CLI --extensions-dir ~/.vscode-server/extensions --install-extension "$extension"
    done
  fi
  set -e
fi

from envbuilder.

I've been exploring solutions to this issue and the approach that stands out the most is that we support installing extensions from devcontainer.json within Coder modules and via Dev Container features.

Currently, envbuilder lacks awareness of both VS Code Server and code-server. It makes sense for envbuilder to remain agnostic about specific customizations.

If we look at Codespaces, the VS Code extensions from devcontainer.json are installed as part of the integrated editor for the Codespaces container. The editor is not actually defined in the devcontainer.json, it's a feature of Codespaces. If envbuilder shipped with an integrated editor like Codespaces, then placing that logic within envbuilder would be sensible.

The use-case that we probably should enable (either via envbuilder itself of @devcontainer/cli) is to allow composing a devcontainer.json that is resolved from the projects devcontainer.json and features. Then documenting how to use this.

Examples of this exists in Tool Examples over at @devcontainers/cli.

We can observe that e.g. tool-vscode-server has scripts for both composing the devcontainer.json and installing extensions.

Thoughts? How should we take envbuilder forward?

Related issues:

• #43
• #89

Side-note: I've also noticed that the "entrypoint" from Dev Container features doesn't get launched via envbuilder. Similarly, envbuilder doesn't respect the final CMD (or ENTRYPOINT?) in container images and replaces these with its own "sleep for infinity", even when the init script is ommited. It's a bit unclear to me how we should handle this.

from envbuilder.

@bpmct In theory I like that idea, but in practice I think pushing this information back to the provider could be challenging and have support for only a limited number of use-cases. One of the issues is that we should also consider the JSON pulled in via Dev container features, this is only available at build time or in the final image. Without a way to propagate this information from envbuilder to provider, it'd be challenging to do in a robust way.

Two options I think are feasible (for support in e.g. code-server module):

1. Allow running envbuilder read-configuration to have envbuilder produce the JSON
2. Provide a well-known place (or env variable) where the finalized JSON produced by envbuilder is available

I like option 1. since it's what @devcontainer/cli does and allows inclusion of additional JSON. If we match @devcontainer/cli API here and alias envbuilder -> devcontainer, we could make this a very generic solution for anyone building devcontainer functionality that just works ™️ in envbuilder.

Option 2 is more limited but means we don't need to support an API/CLI args.

from envbuilder.

I confirm that support for installing VS Code Extensions based on devcontainer.json is highly anticipated by many users.

from envbuilder.

if ! which code-server > /dev/null; then
curl -fsSL https://code-server.dev/install.sh | sh | tee code-server-install.log
fi
CODE_CLI=code-server
if code; then
CODE_CLI=code
fi
mkdir -p ~/.vscode-server/extensions

set +e
extensions=( $(sed 's///.*$//g' */.devcontainer/devcontainer.json | jq -r -M '[.customizations.vscode.extensions[]?, .extensions[]?] | .[]' ) )
if [ "$${extensions[0]}" != "" ] && [ "$${extensions[0]}" != "null" ]; then
for extension in "$${extensions[@]}"; do
$CODE_CLI --extensions-dir ~/.vscode-server/extensions --install-extension "$extension"
done
fi
set -e

Hi! I would like to apply your solution. What place are you injected these code?

from envbuilder.

I wonder if this is something our envbuilder Terraform provider we need to build can solve. It'd be excellent if the envbuilder provider can provide a raw json object of the full dev container file, which then the code-server module could consume (to then run code-server --install-extension ... on a loop). The code-server module also has support for VS Code settings

from envbuilder.

Related: #121

from envbuilder.

I like option 1 too :)

from envbuilder.

@mafredri to resolve this issue in favor of smaller subtasks

from envbuilder.

This has now been broken out into separate features.

• #212
• #211
• #210
• coder/modules#253

Closing this issue as not planned.

from envbuilder.