Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Support Windows container images

Ouverte
  • Quelque chose ne va pas ?
#1,328 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
12/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
docker, typescript
Domaine
cli, devtools

Piste de recherche

Start with the open scope question in the issue: whether Windows container support belongs here or waits on microsoft/vscode-remote-release#445, and whether features should be OS-aware or fail fast. The Linux assumptions it lists are in singleContainer.ts and dockerCompose.ts (the hardcoded /bin/sh entrypoint), the /workspaces/<name> bind mount, and the /tmp helper copies. Done would be an agreed design plus a prototype of the bring-up and exec path. Do not start coding until maintainers answer the scope question.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

  • Only Linux container images can be targeted today. On a Windows host with the daemon in
    Windows-container mode the CLI fails somewhere in the mount, entrypoint or exec path, and the
    errors never point at the image OS (that is what #449 chased). The extension side is tracked in
    microsoft/vscode-remote-release#445, but the CLI is what builds the image, mounts the workspace and
    execs into the container, so scoping it here seems reasonable; CLI support would also make
    devcontainer up/exec usable from a terminal on Windows containers.

  • The Linux assumptions I know of: the workspace is bind mounted to /workspaces/<name>, the
    entrypoint is hardcoded to /bin/sh in singleContainer.ts and dockerCompose.ts, lifecycle
    commands and userEnvProbe go through a POSIX login shell, and helper scripts are copied to
    /tmp. Supporting Windows containers would mean detecting the target OS, translating the workspace
    and user mounts to Windows form (drive letters, npipe for Docker-out-of-Docker), and using cmd
    or pwsh for exec and lifecycle. Features are the open question, since install.sh is the
    entrypoint; either the spec grows an OS-aware mechanism or the CLI fails fast for Linux-only
    features.

  • Is this in scope here, or intentionally gated on #445? Happy to contribute, starting with a design
    discussion and a small prototype for the bring-up and exec path.

Langage dominant
TypeScript
Étoiles
3k
Forks
466
Merge moyen
13 h 28 min
PR mergées (30 j)
2

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de devcontainers/cli

Toutes les issues de devcontainers/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.