Automatizar la compilación de imágenes Docker y subirlas a registries en la nube es la segunda pieza clave de un flujo de integración continua con GitHub Actions. Aquí verás cómo configurar un workflow que publique tu imagen en AWS ECR, Google Artifact Registry o Azure Container Registry, eligiendo el proveedor según tu caso.

¿Cómo se dispara el workflow de build en GitHub Actions?

El workflow de build arranca con dos triggers bien definidos que te dan flexibilidad para automatizar o lanzar manualmente la compilación.

• workflow_dispatch: te permite ejecutarlo manualmente desde la pestaña Actions, recibiendo un input de tipo choice con tres opciones: AWS, GCP o Azure.
• issue_comment: se activa cuando alguien crea un comentario en un issue o pull request, y solo cuando el evento es created [01:00].

Cada job tiene un condicional con if que verifica dos cosas: que el evento sea un pull request y que el body del comentario contenga un substring como build AWS, build GCP o build Azure. Con el operador or, también se ejecuta si el input del workflow dispatch coincide con el proveedor.

¿Qué es un workflow_dispatch en GitHub Actions? Es un trigger que permite ejecutar un workflow manualmente desde la interfaz de GitHub, opcionalmente recibiendo inputs configurables como listas desplegables.

¿Cómo subir una imagen Docker a AWS ECR desde GitHub Actions?

El job Docker AWS corre sobre Ubuntu y sigue una secuencia clara para preparar el entorno y publicar la imagen en el Elastic Container Registry [03:30].

Pasos para configurar el entorno de compilación

Antes de tocar AWS, el job prepara Docker para soportar múltiples arquitecturas. Esto es lo que necesitas:

1. Clonar el repositorio con actions/checkout para tener todos los archivos disponibles.
2. Configurar QEMU mediante el action oficial docker/setup-qemu-action en su versión 2.1.0, que habilita la emulación para distintas arquitecturas.
3. Configurar Docker Buildx con docker/setup-buildx-action versión 2.5.0, una forma recomendada para producción que da mayor control sobre la compilación.
4. Definir el tag de la imagen: si la rama es master, usa latest; si no, usa snapshot.

En ese mismo paso se guardan variables como BCS_ref y build_date en GITHUB_ENV, las variables de entorno automáticas que GitHub expone para que los siguientes pasos del job puedan leerlas. Son opcionales pero recomendadas por el maintainer del proyecto, en este caso OWASP.

Autenticación y push al ECR público

Para subir la imagen, primero te autenticas con configure-aws-credentials versión 2.0.0, pasándole un access key ID y un secret access key de un usuario IAM como secretos. La región va como variable de entorno, ya que no es información sensible.

Luego, el action amazon-ecr-login configurado con registry-type: public te logea en el ECR. La elección de repositorio público responde a algo concreto: AWS ofrece 50 GB gratis en repositorios públicos, frente a solo 500 MB en privados.

Finalmente, docker/build-push-action compila y publica la imagen. Los parámetros importantes son:

• file: ruta al Dockerfile.
• context: el punto . indica la raíz del repo.
• platforms: linux/amd64 y linux/arm64, las dos arquitecturas más comunes.
• push: true para subir efectivamente al registry.
• tags: construido con la variable registry (output del paso de login), el alias del registry, el repositorio y el tag de Docker calculado antes.

¿Qué es Docker Buildx? Es una extensión de Docker que permite compilar imágenes para múltiples plataformas y arquitecturas desde un mismo runner, con mejor control que el build tradicional.

¿Cómo publicar la misma imagen en Google Artifact Registry y Azure Container Registry?

La lógica se repite, pero cambia la autenticación y la ruta del registry según el proveedor [09:30].

Configuración para Google Cloud Platform

En GCP, el equivalente al ECR se llama Artifact Registry. El flujo agrega un paso con el action oficial google-github-actions/auth, que recibe el project ID (guardado como variable de entorno) y un key de una service account. Configuras el formato del token como access_token.

Después, en lugar de usar un action propio de Google para Docker, se usa docker/login-action con estos parámetros:

• username: oauth2accesstoken.
• password: el access token generado por el paso anterior, leído como output automático.
• registry: la ruta del Artifact Registry.

El push usa el mismo build-push-action, pero el formato del tag incluye región, ID del proyecto, nombre del proyecto, nombre de la imagen y el tag de Docker.

Configuración para Microsoft Azure

En Azure el registry se llama Azure Container Registry. El job usa dos actions de Azure: azure/login, que recibe unas Azure credentials como secreto, y azure/docker-login, que pide un login-server con el nombre del registry, además de username y password como secretos.

El paso final de compilación y push mantiene los mismos parámetros del action de Docker, ajustando únicamente cómo se construye la ruta: registry_name, image_name y el tag.

¿Por qué elegir un proveedor cloud sobre otro para tus imágenes Docker?

No necesitas usar los tres proveedores en un proyecto real. La elección depende de tus créditos, comodidad y caso de uso. Si no tienes un proveedor predefinido, hay dos recomendaciones prácticas basadas en las capas gratuitas:

• Usa el registry público de AWS ECR para almacenar imágenes, por sus 50 GB gratis.
• Usa GCP para desplegar containers serverless, ya que su capa gratuita es más generosa que la de AWS o Azure para correr contenedores.

En la pestaña Actions puedes ver cómo se ejecutan estos workflows. Un build completo del proyecto OWASP puede tardar 3 horas y 25 minutos la primera vez, porque la imagen es grande y tiene mucho que compilar; las siguientes corridas suelen ser más rápidas. Para lanzarlo manualmente, vas a Run workflow, eliges la rama y el proveedor cloud desde el desplegable.

Si ya completaste tu primer flujo de integración continua, compártelo en redes y etiqueta al instructor en los comentarios para revisarlo en conjunto.