Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Support Windows container images

Offen
  • Stimmt etwas nicht?
#1,328 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
12/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker, typescript
Bereich
cli, devtools

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
TypeScript
Sterne
3k
Forks
466
Ø Merge
13 Std. 28 Min.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus devcontainers/cli

Alle Issues in devcontainers/cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.