77 lines
6.5 KiB
Markdown
77 lines
6.5 KiB
Markdown
# 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).
|
|
|
|
```dockerfile
|
|
#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:
|
|
|
|
```yaml
|
|
- 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.
|