83 lines
4.5 KiB
Markdown
83 lines
4.5 KiB
Markdown
# 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](Dockerfile#L14):
|
|
|
|
```
|
|
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](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.
|
|
|
|
```dockerfile
|
|
# 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](README.md#L11) 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.
|
|
|
|
1. `git add Dockerfile README.md`
|
|
2. `git commit -m "Fix VS Code apt source breaking apt-get update on the base image"`
|
|
3. `git tag v1.2.2`
|
|
4. `git push origin master`
|
|
5. `git push origin v1.2.2`
|
|
|
|
## Verificación
|
|
|
|
1. 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`.
|
|
2. 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.
|
|
3. (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.
|