Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support Windows container images

Abierto
  • ¿Algo no está bien?
#1,328 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, typescript
Área
cli, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
3k
Forks
466
Merge medio
13 h 28 min
PR fusionados (30 d)
2

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de devcontainers/cli

Todos los issues de devcontainers/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.