qwen3-6-lora/data/raw/sanitized/plans/en-la-version-de-hashed-hoare.md

Fix: VSCode se instala en versión vieja en la imagen ARM64

Contexto

Este repo construye una imagen Docker multi-arquitectura (linux/amd64 + linux/arm64) vía GitHub Actions (.github/workflows/main-workflow.yml), instalando VSCode (code) dentro de un ubuntu:22.04 para exponerlo vía code tunnel (ver entrypoint.sh).

El usuario reportó que la build ARM instala una versión vieja de VSCode mientras que x86 sí instala la última. Investigación (Dockerfile completo, historial de git, y research web) confirmó:

• El bloque de instalación de VSCode (Dockerfile:30-38) usa dpkg --print-architecture de forma dinámica y correcta para ambas arquitecturas — no hay hardcode ni bug de arquitectura en el código.
• El bloque instala vía apt-get install -y code contra el repo apt packages.microsoft.com/repos/vscode stable. Ese repo no publica los .deb de amd64 y arm64 de forma atómica/simultánea — el proceso de firmado/publicación de Microsoft puede tener horas de desfase entre arquitecturas (documentado en issues del propio repo de microsoft/vscode, incluyendo un caso donde el build de amd64 faltaba mientras arm64 ya estaba publicado). Como el job de CI construye ambas plataformas en la misma corrida, si arm64 aún no tiene el paquete nuevo publicado en el índice apt en ese instante, la imagen arm64 termina con una versión más vieja que la de amd64.
• Hallazgo secundario: el workflow nunca configura docker/setup-qemu-action para registrar la emulación de arm64 en el runner amd64 de GitHub — actualmente funciona porque el runner probablemente trae binfmt registrado por defecto, pero es una dependencia implícita no documentada.

Decisión ya tomada con el usuario: en vez de pinnear una versión exacta, se reemplaza el mecanismo de instalación para descargar el .deb directamente desde el endpoint canónico de Microsoft (update.code.visualstudio.com/latest/linux-deb-{arch}/stable), que es la fuente "siempre la última" oficial que usa la propia página de descargas de VSCode, evitando el índice del repo apt que tiene el desfase documentado. Se mantiene el comportamiento actual de "rolling latest" para ambas arquitecturas, pero leyendo de la fuente correcta.

Cambios

1. Dockerfile — reemplazar el bloque de instalación de VSCode (líneas 30-38)

Quitar la dependencia del repo apt de Microsoft (gnupg2, software-properties-common, import de key, add-apt-repository) y reemplazarla por descarga directa + dpkg -i + apt-get install -f -y para resolver dependencias faltantes (una .deb instalada con dpkg -i en una imagen mínima de Ubuntu típicamente falla por dependencias no resueltas — eso es normal y se arregla con el apt-get install -f -y inmediatamente después).

#Instalando VSCode
RUN ARCH="$(dpkg --print-architecture)" \
    && case "${ARCH}" in \
         amd64) VSCODE_ARCH="x64" ;; \
         arm64) VSCODE_ARCH="arm64" ;; \
         *) echo "Unsupported architecture: ${ARCH}" >&2; exit 1 ;; \
       esac \
    && curl -fsSL "https://update.code.visualstudio.com/latest/linux-deb-${VSCODE_ARCH}/stable" -o /tmp/vscode.deb \
    && (sudo dpkg -i /tmp/vscode.deb || true) \
    && sudo apt-get update \
    && sudo DEBIAN_FRONTEND=noninteractive apt-get install -f -y \
    && rm -f /tmp/vscode.deb

Notas importantes sobre esta forma exacta (difiere levemente del primer borrador que salió del research, ya corregido aquí):

• El case mapea amd64 → x64 y arm64 → arm64 (así nombra Microsoft los paths de descarga), y falla explícito ante cualquier otra arquitectura en vez de descargar algo inválido silenciosamente.
• (sudo dpkg -i /tmp/vscode.deb || true) va entre paréntesis — así el || true sólo absorbe el fallo esperado de dependencias de dpkg -i, sin enmascarar un fallo del curl anterior (si el && completo se escribe sin paréntesis, un curl fallido también quedaría "perdonado" por el || true y la imagen se armaría sin VSCode instalado, sin que el build falle — bug a evitar).
• curl ya está instalado antes en el Dockerfile (línea 8), no hace falta agregarlo.
• Ya no se necesitan gnupg2, software-properties-common, el wget | apt-key add, ni add-apt-repository — se eliminan del bloque. Confirmado que nada más adelante en el Dockerfile (DevTunnel, chmod, entrypoint) depende de esos paquetes.
• rm -f /tmp/vscode.deb limpia el .deb descargado en la misma capa.

2. .github/workflows/main-workflow.yml — agregar setup-qemu-action explícito

Antes del step "Set up Docker Buildx" (líneas 14-15), agregar:

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

Alcance acotado a propósito: no se actualizan las demás actions del workflow (actions/checkout@v2, docker/setup-buildx-action@v1, docker/login-action@v1, docker/build-push-action@v2), ya que son cambios no relacionados al bug de emulación/versión que se está resolviendo. Un bump general de versiones de actions sería un cambio deliberado aparte, si se quiere hacer.

3. version.txt

Bump de 3.2.23 a 3.2.24, siguiendo la convención existente del repo de bumpear este archivo junto con cambios al Dockerfile/instalación de VSCode (ver historial de commits).

Archivos a modificar

• Dockerfile
• .github/workflows/main-workflow.yml
• version.txt

Verificación

1. Build local nativo (sin emulación) para confirmar que el flujo x86 sigue funcionando: docker buildx build --platform linux/amd64 -t test-amd64 --load . docker run --rm test-amd64 code --version
2. Build local con emulación arm64 (requiere QEMU registrado localmente, p.ej. Docker Desktop ya lo trae, o docker run --privileged --rm tonistiigi/binfmt --install all): docker buildx build --platform linux/arm64 -t test-arm64 --load . docker run --rm --platform linux/arm64 test-arm64 code --version
3. Comparar el output de code --version (versión + commit hash) entre ambos — deben coincidir, confirmando que el bug de desfase quedó resuelto.
4. Sanity check de que el binario resuelve sus dependencias en runtime (no solo que el archivo existe): docker run --rm test-amd64 code tunnel --help.
5. Si no es viable correr la build emulada localmente, hacer push a master para disparar main-workflow.yml, y luego comparar docker run --rm --platform linux/arm64 aleleba/vscode:latest code --version vs --platform linux/amd64 contra la imagen recién publicada.