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