qwen3-6-lora/data/raw/sanitized/plans/quiero-agregarle-soporte-a-toasty-dusk.md

Soporte multi-arquitectura (amd64 + arm64) para vscode-server

Contexto

La imagen vscode-server hoy solo se construye y publica para linux/amd64 (ver .gitea/workflows/main-workflow.yml:85). El usuario quiere consumir esta imagen nativamente desde una Mac con chip Apple Silicon (arm64), y seguir publicándola en el registry de Gitea (gitea.p-lao.com/aleleba/vscode-server).

La imagen base gitea.p-lao.com/aleleba/vscode:latest (repo aleleba/aleleba-vscode-dockerfile-configuration) ya se publica multi-arch (confirmado: su workflow construye con platforms: linux/amd64,linux/arm64 y su Dockerfile usa $(dpkg --print-architecture) para resolver rutas dependientes de arquitectura), así que es una base válida para extender.

Al revisar Dockerfile completo se encontraron dos problemas que romperían o degradarían el build en arm64, y ambos ya se resolvieron con el usuario:

1. JAVA_HOME hardcodeado a amd64 (Dockerfile:106, y de nuevo en el ~/.bashrc en Dockerfile:160) — en Debian/Ubuntu la ruta de openjdk-17-jdk es /usr/lib/jvm/java-17-openjdk-<arch>, así que en arm64 esa ruta no existiría y rompería cualquier comando que dependa de $JAVA_HOME (Android SDK, Gradle, etc.).
2. docker-compose v1.21.2 descargado como binario fijo (Dockerfile:76-80) desde https://github.com/docker/compose/releases/download/1.21.2/docker-compose-$(uname -s)-$(uname -m) — se confirmó por búsqueda web que esa versión (2018) nunca publicó binario para aarch64/arm64; el RUN fallaría al construir en esa plataforma.

Decisiones ya acordadas con el usuario:

• docker-compose: eliminar la descarga manual del binario v1 y confiar en el plugin Compose V2 (docker compose, con espacio) que el script de get.docker.com ya instala automáticamente y que sí soporta ambas arquitecturas nativamente. Agregar un wrapper /usr/local/bin/docker-compose que delegue a docker compose "$@", para no romper scripts existentes que usan el nombre con guion.
• Android SDK (platform-tools, build-tools, emulator instalados vía sdkmanager, Dockerfile:130-131): Google solo distribuye binarios nativos oficiales para Linux x86_64. El build en sí no falla en arm64 (sdkmanager solo descarga/descomprime, no ejecuta los binarios), pero en un Mac M corriendo la imagen arm64 nativa, adb/aapt2/emulator probablemente no ejecutarán. Se deja la instalación igual en ambas arquitecturas y se documenta la limitación en el README (mitigación: correr ese contenedor puntual con --platform linux/amd64 cuando se necesite Android).

El resto de las instalaciones del Dockerfile (GitHub CLI, kubectl, Flux CLI, NVM/Node, Emscripten, Claude Code, Conan) ya son multi-arch (usan $(dpkg --print-architecture), scripts oficiales que autodetectan arquitectura, o son artefactos JVM/Python agnósticos de arquitectura) — no requieren cambios.

Cambios

1. Dockerfile

• Justo antes de ENV JAVA_HOME=... (línea 106), declarar ARG TARGETARCH (buildx lo puebla automáticamente por plataforma; sus valores amd64/arm64 coinciden con el naming de Debian) y cambiar la línea a:

  ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-${TARGETARCH}
  

• En el bloque de configuración de ~/.bashrc (línea ~160), reemplazar el valor hardcodeado por la variable ya resuelta:

  RUN echo "export JAVA_HOME=$JAVA_HOME" | sudo tee -a ~/.bashrc
  

• Eliminar el bloque de instalación manual de docker-compose v1 (líneas 76-80).
• Después de instalar Docker (que ya trae docker-compose-plugin), agregar un wrapper de compatibilidad:

  RUN sudo printf '#!/bin/sh\nexec docker compose "$@"\n' | sudo tee /usr/local/bin/docker-compose > /dev/null \
      && sudo chmod +x /usr/local/bin/docker-compose
  

2. .gitea/workflows/main-workflow.yml

• Agregar el paso docker/setup-qemu-action@v3 (antes de docker/setup-buildx-action@v3), para garantizar emulación arm64 en el runner de Gitea Actions aunque no traiga QEMU/binfmt preregistrado (a diferencia de runners hosteados de GitHub).
• Cambiar platforms: linux/amd64 (línea 85) a platforms: linux/amd64,linux/arm64.

3. README.md

• Bump de versión siguiendo la convención existente del repo (cada commit incrementa la versión): 1.1.0 → 1.2.0.
• Agregar una nota breve documentando la limitación de Android SDK en arm64 y la mitigación (--platform linux/amd64 cuando se necesite adb/aapt2/emulator funcionales).

Verificación

• Build local multi-plataforma sin push, solo para validar que ambos targets compilan:

  docker buildx build --platform linux/amd64,linux/arm64 -t vscode-server:test --output=type=cacheonly .
  

• Si hace falta cargar y probar arm64 localmente en una máquina x86 (requiere QEMU registrado, p.ej. docker run --privileged --rm tonistiigi/binfmt --install all):

  docker buildx build --platform linux/arm64 -t vscode-server:arm64 --load .
  docker run --rm --platform linux/arm64 vscode-server:arm64 bash -lc 'echo $JAVA_HOME && java -version && docker compose version && docker-compose version'
  

• Push a master (o workflow_dispatch) y confirmar en Gitea Actions que el job build-and-push termina en verde para ambas plataformas.
• Verificar el manifest multi-arch publicado:

  docker manifest inspect gitea.p-lao.com/aleleba/vscode-server:latest
  

  y confirmar que aparecen entradas para linux/amd64 y linux/arm64.