microsoft / microsoft/vscode-remote-release

`initializeCommand` implementation and documentation don't align

Open
#8,577 1 comment 0 reactions 1 assignee View on GitHub

@chrmarti is already working on this.

Since Dec 16, 2024.

bug containers doc
Dominant language
Dockerfile
Stars
4.2k
Forks
470
Avg merge
1d 1h
Merged PRs (30d)
1

Description

  • VSCode Version:1.78.2
  • Local OS Version: Mac OS Ventura 13.3.1
  • Remote OS Version: N/A
  • Remote Extension/Connection Type: Containers/WSL/Server
  • Logs:

Steps to Reproduce:

  1. Create a new devcontainer.
  2. Add an initializeCommand to the devcontainer in .devcontainer.json. For example:
#!/usr/bin/env bash
# .devcontainer/initialize-command.sh
set -e

echo "Initializing the dev container!!!!"
sleep 20;

devcontainer.json:

"initializeCommand": "./.devcontainer/initialize-command.sh",
  1. Open the project in a dev container.
  2. Once the devcontainer has finished building, close the workspace.
  3. Go to "Open Recent" and reopen the workspace with the devcontainer

EXPECTED: As per the devcontainer lifecycle scripts documentation, you should see an echo when the container is first created but no echo when the container is reopened because the container has already been created.

ACTUAL: initializeCommand is run every time the workspace is reopened. I think this maps more to preStartCommand than the preCreateCommand.

As per the devcontainer spec, initializeCommand` is "a command string or list of command arguments to run on the host machine before the container is created."

As far as I can tell, this either means that:

  1. The devcontainer spec documentation is wrong or
  2. VSCode isn't following the spec here

Does this issue occur when you try this locally?: Yes
Does this issue occur when you try this locally and all extensions are disabled?: Yes

@chrmarti, who helped implement this initially

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.