4.5CI: construir y subir una imagen en cada commit
Lo esencial en 30 segundos
- La CI es la única fábrica de imágenes : en cada push a main, recupera el código, se conecta al registro y construye + sube — se acabaron los builds « a mano en el portátil ».
- Se etiqueta SHA + versión : la huella del commit para la trazabilidad exacta, la versión para la legibilidad — la producción despliega el SHA o la versión, nunca un alias móvil.
- Reflejo de Idir : caché activado para builds rápidos, credenciales en secretos del repositorio, nunca en el archivo de workflow.
Mini-caso hilado — Idir conecta la fábrica de imágenes de su equipo
Idir, devops junior en Argel, está harto de las imágenes construidas a mano cuyo contenido nadie conoce : escribe un workflow que, en cada push a main, se conecta a GHCR vía el token del repositorio, construye con caché y sube la imagen etiquetada con la huella del commit. El equipo luego descarga la imagen del commit exacto. Último hito del hilo : cada commit da una imagen desplegable y trazable, sin intervención manual.
Último caso del hilo 4.1-4.5 — Idir cierra su nivel : publicar, fiabilizar, exponer, guardar, automatizar.
1. El pipeline mínimo que lo cambia todo
En cada push a main : recuperación del código, conexión al registro (secreto del repositorio), build + push etiquetados. Ningún build más « a mano en el portátil » : la CI es la única fábrica de imágenes — como la fábrica de Idir, cada imagen tiene un origen conocido.
Y solo se versiona lo verde : un job de tests antes del build evita subir imágenes rotas.
2. Etiquetar inteligentemente en CI
Se sube la huella del commit (trazabilidad exacta : esta imagen = este código) + la versión (legible, sobre tag git) + un alias de rama en desarrollo. En producción se despliega la huella o la versión, nunca un alias móvil — Idir puede así redesplegar exactamente el commit validado.
Subir solo el alias móvil es volver a ser intrazable : el pipeline siempre debe producir al menos un tag exacto.
3. Caché y secretos : los dos ajustes
La caché reutiliza las capas entre runs y divide los tiempos de build. Las credenciales viven en secretos del repositorio, nunca en el archivo de workflow. Un pipeline que muestra un secreto en los logs es un pipeline por corregir con urgencia — luego se revoca el secreto expuesto.
Permiso mínimo : el job solo recibe los derechos que necesita (escritura de paquetes, nada más).
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Workflow GitHub Actions mínimo
La fábrica de Idir : conexión por token del repositorio, build + push de la huella.
name: image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
permissions:
packages: write
steps:
- uses: actions/checkout@v4
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
push: true
tags: ghcr.io/monequipe/app:${{ github.sha }}Lectura : conexión por token automático, build + push de la huella del commit.
Lección : cada commit da una imagen desplegable y trazable.
Vocabulario de la sección
- Pipeline
- La CADENA automática : test, luego build, luego push (luego despliegue).
Ejemplo sencillo: En cada push, la fábrica de Idir prueba, construye y sube sin intervención.
Lo que no es: comandos tecleados a mano en un portátil.
Reflejo: repetir un build a mano : escribirlo en pipeline.
- SHA
- La HUELLA del commit : tag de trazabilidad exacta (esta imagen = este código).
Ejemplo sencillo: Idir redespliega exactamente la imagen del commit validado.
Lo que no es: un alias móvil que cambia de contenido.
Reflejo: producción : desplegar una huella o una versión, nunca un alias.
- Secreto CI
- Variable SENSIBLE guardada en el repositorio, oculta de los logs y nunca escrita en el archivo.
Ejemplo sencillo: El token de registro de Idir vive como secreto, no en el workflow.
Lo que no es: una contraseña pegada en claro en el archivo.
Reflejo: credencial en CI : secreto del repositorio, siempre.
- Fábrica única
- Solo la CI produce las imágenes desplegadas : origen conocido, builds reproducibles.
Ejemplo sencillo: El equipo de Idir solo despliega imágenes salidas del pipeline.
Lo que no es: imágenes subidas « rápido » desde un portátil.
Reflejo: imagen de origen desconocido : prohibir, pasar por la CI.
En la práctica — En práctica — Su primera fábrica
- Cree el workflow de arriba en .github/workflows/image.yml.
- Suba a main y siga el run (¿verde?).
- Verifique la imagen etiquetada en los paquetes del registro.
- Descárguela y láncela : el commit corre.
Guion listo para decir — anunciar la fábrica al equipo (30 s)
« Soy Idir : en cada push a main, la CI prueba, construye con caché y sube la imagen etiquetada con la huella del commit. El token queda como secreto del repositorio, nunca en el archivo. Desplegamos la huella exacta : se acabaron las imágenes cuyo contenido nadie conoce. »
Para decir en revisión : muestre el run verde y la imagen del commit en el registro.
Modelo copiar-pegar — workflow build + push (genérico, válido)
name: image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
context: .
push: true
tags: ghcr.io/monequipe/app:${{ github.sha }}Versión legible además
Como Idir : huella del commit + versión sobre tag git — trazabilidad exacta y lectura humana.
Builds demasiado lentos
Activar la caché entre runs : las capas sin cambios se reutilizan, los builds se dividen.
Imagen rota subida
Añadir el job de tests antes del build : solo se versiona lo verde.
Secreto mostrado en log
Corregir con urgencia, retirar toda muestra de depuración, luego revocar y sustituir el secreto expuesto.
✓ Buenas prácticas
- Tag exacto sistemático + versión sobre tag git.
- Activar la caché de los builds.
- Secretos en secretos del repositorio, nunca en claro.
✗ Errores frecuentes
- Construir en local y luego subir « rápido ».
- Subir solo el alias móvil (intrazable).
- Mostrar un secreto en echo de depuración.
Puntos clave
- La CI construye + sube, no el portátil.
- Huella = trazabilidad, versión = legibilidad.
- Caché = builds rápidos.
- Secretos fuera del workflow, siempre.
Reto 48h — aplique mañana
En un repositorio real : cree el workflow, suba a main, verifique la imagen etiquetada en el registro y luego láncela.
- Sé escribir un workflow build + push disparado en main.
- Sé etiquetar huella + versión y desplegar lo exacto.
- Sé gestionar secretos, caché y permisos mínimos.
Preguntas frecuentes
¿Probar antes de construir?
Sí : un job de tests antes del build evita subir imágenes rotas. Solo se versiona lo verde.
¿Y el despliegue auto?
Paso siguiente : primero una fábrica fiable (build + push trazables), luego la entrega. Sin fábrica fiable, automatizar el despliegue solo acelera los errores.
En CI, ¿qué tag desplegar en producción?