Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support Windows container images

Aperta
  • Qualcosa non va?
#1,328 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, typescript
Ambito
cli, devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

  • 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.

Lingua principale
TypeScript
Stelle
3k
Fork
466
Merge medio
13h 28m
PR unite (30g)
2

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di devcontainers/cli

Tutte le issue di devcontainers/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.