Fix CI: apt-get update falla tras actualizar la imagen base

Contexto

El pipeline de vscode-server (.gitea/workflows/main-workflow.yml) construye la imagen a partir de FROM gitea.p-lao.com/aleleba/vscode:latest, publicada manualmente desde el repo separado aleleba-vscode-dockerfile-configuration (sin CI propia — se sube a mano).

Revisé el log del run fallido (run #34, job 1542, https://gitea.p-lao.com/aleleba/vscode-server/actions/runs/34/jobs/0) y el primer paso que rompe es RUN sudo apt-get update en Dockerfile:14:

Err:4 https://packages.microsoft.com/repos/code stable InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB3E94ADBE1229CF
E: The repository 'https://packages.microsoft.com/repos/code stable InRelease' is not signed.

Causa raíz: el Dockerfile de la imagen base agrega el repo de VS Code a mano vía add-apt-repository "deb [arch=...] https://packages.microsoft.com/repos/vscode stable main" y confía la clave de Microsoft con el método legacy apt-key add (keyring global /etc/apt/trusted.gpg). Pero el propio paquete .deb de code (instalado sin versión fija, siempre "latest") sobreescribe /etc/apt/sources.list.d/vscode.list apuntando a una ruta distinta — https://packages.microsoft.com/repos/code — y añadiendo signed-by=/etc/apt/keyrings/packages.microsoft.gpg, un keyring que el Dockerfile de la imagen base nunca crea. Como ese Dockerfile no vuelve a correr apt-get update después de instalar code, el problema queda dormido en la imagen — y sólo se dispara la próxima vez que alguien corre apt-get update sobre esa capa, que es justo lo primero que hace vscode-server en su propio Dockerfile. Esto explica por qué el mismo commit (62a2849) tuvo corridas exitosas (#32, #33) y luego falló (#34): la imagen :latest cambió por debajo (rebuild manual del usuario) sin que cambiara el código de este repo.

Se optó por resolverlo del lado de vscode-server (en vez de tocar el repo de la imagen base, que no está abierto en esta sesión) porque desbloquea el CI de inmediato y no depende de reconstruir/republicar la imagen base.

Cambio

En Dockerfile, antes del RUN sudo apt-get update inicial (línea 14), eliminar el archivo de fuentes de VS Code que quedó roto — ya no hace falta: code ya está instalado en la imagen base, y este repo no necesita volver a instalarlo ni actualizarlo.

# Single apt update at the beginning

# The VS Code apt source baked into the base image points at a signed-by keyring
# that was never created, breaking `apt-get update` on any layer built on top of it.
# code is already installed in the base image, so this repo doesn't need the repo entry.
RUN sudo rm -f /etc/apt/sources.list.d/vscode.list /etc/apt/sources.list.d/vscode.sources

RUN sudo apt-get update

No se requieren más cambios en el Dockerfile: el resto de los pasos y el workflow de Gitea Actions no están involucrados en el fallo.

Bump de versión en README

El README.md trae un ## Version (actualmente 1.2.1) que se incrementa manualmente en cada cambio publicable. Subir a 1.2.2 (patch, es un fix) junto con el cambio del Dockerfile.

Commit, tag y push

Este repo no usa PRs: los cambios van directo a master y el push dispara el workflow (on: push: branches: [ master ]). Además se tagea la versión para dejar un punto de referencia.

git add Dockerfile README.md
git commit -m "Fix VS Code apt source breaking apt-get update on the base image"
git tag v1.2.2
git push origin master
git push origin v1.2.2

Verificación

Ejecutar docker build --platform linux/amd64 -t vscode-server-test . localmente (o docker buildx build --platform linux/amd64,linux/arm64 ... para replicar el multi-arch del CI) y confirmar que el paso apt-get update y la instalación de paquetes completan sin el error NO_PUBKEY.
Tras el push, confirmar en https://gitea.p-lao.com/aleleba/vscode-server/actions que el job build-and-push termina en verde para ambas plataformas.
(Opcional, recomendado para evitar que el problema reaparezca en la imagen base) Actualizar el Dockerfile de aleleba-vscode-dockerfile-configuration para usar el método moderno signed-by en vez de apt-key add, de forma que la clave quede en el mismo keyring que el paquete code espera. Esto queda fuera del alcance de este cambio ya que ese repo no está abierto en esta sesión.

4.5 KiB Raw Permalink Blame History