Fase 2: 04_sanitize.py - scrubbing de secretos de skills/agentes/plans (10 secretos unicos, gate en verde)

2026-07-29 00:35:59 +00:00
parent 21bc219f31
commit 837f91060f
79 changed files with 10153 additions and 0 deletions
@@ -0,0 +1,82 @@
+# 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.