# 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`.