Iba fijado por digest porque su tag "latest" no es una release sino una build
de la rama main (org.opencontainers.image.version=main). Al mirarlo de cerca,
ese digest resultó ser EXACTAMENTE v1.70.0: el commit 4b351bb es su propio
release commit. O sea, ya corría el código de una release, sólo que sin poder
saberlo desde el manifiesto.
Se sube a v1.71.0 (17-jul), una menor por delante, en vez de quedarse en la
v1.70.0 equivalente: es la última publicada y arregla justo algo de base de
datos — "restore widget_secret migration journal entries accidentally removed".
Sin cambios rompedores en las notas.
Homarr guarda una SQLite en homarr-db-pvc, así que esto aplica migraciones y no
es un pin inocuo como los otros seis. Copia consistente antes de tocar, con el
pod parado para no copiar una escritura a medias:
/data/backups/backups/homarr_pre-v1.71.0_2026-07-22_10-02-23.tar.gz
(además del backup diario, que ya cubría homarr).
Verificado tras arrancar: "Migration complete" en el log, 200 en
home.chemavx.xyz, OIDC contra Authentik intacto, y los datos en su sitio —
consultada la SQLite en solo lectura: el tablero Dashboard_ChemaVX con sus 7
items, 7 apps, 1 integración y los 2 usuarios.
Los dos "Board not found" del log llevan la hora exacta de mis curl anónimos:
un visitante sin sesión no tiene tablero. No es un fallo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El commit 22ae5d7 (15-abr) fijó estos tags EN GIT pero nunca se aplicó al
cluster: estos namespaces no están en ArgoCD, así que un cambio en git no llega
solo. Tres meses después git decía 1.25.5 y gitea corría 1.27.0, subido en algún
reinicio sin que nadie lo decidiera. Ahora se fija a los dos lados.
gitea gitea/gitea:latest -> gitea/gitea:1.27.0
gitea (init) busybox -> busybox:1.38.0
gitea-runner gitea/act_runner:latest -> gitea/act_runner:0.6.1
gitea-runner docker:24-dind -> docker:24.0.9-dind
authentik-redis redis:alpine -> redis:8.8.0-alpine
uptime-kuma louislam/uptime-kuma:1 -> louislam/uptime-kuma:1.23.17
homarr homarr:latest -> homarr@sha256:80ee593c...
Los seis primeros se fijan a la MISMA imagen que ya corría: verificado
comparando el repoDigest del tag flotante con el del tag candidato, así que el
reinicio no cambió de versión. Homarr va por digest porque su "latest" es una
build de la rama main (org.opencontainers.image.version=main): no existe un tag
de release que describa lo que corre. Moverlo a una release es otra decisión.
Trampa que casi me come, anotada para la próxima: el imageID de un pod NO
siempre es el digest del registro. Si viene como "repo@sha256:..." lo es; si es
un "sha256:..." pelado es el id local de containerd y NO se puede descargar.
Fijar uptime-kuma a ese id dio ImagePullBackOff; el pod viejo aguantó sirviendo
(maxUnavailable 0 para 1 réplica) y se revirtió sin corte. La comparación buena
es repoDigest contra repoDigest.
De paso, al regenerar gitea-runner desde lo vivo quedan documentados el volumen
buildkitd-config y su montaje, que existían en el cluster y no en git.
Verificado tras cada cambio: rollout completo, versión de la app dentro del pod,
y los cinco servicios respondiendo desde fuera (git 200, home 200, status/auth/
grafana 302 por Authentik). El runner se ha vuelto a registrar en Gitea. Sigue
sin haber pods fuera de Running y las 18 apps de ArgoCD Synced+Healthy.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
chemavxandClaude Opus 4.8