Configurar el despliegue continuo (CD) con Docker Hub en GitHub Actions te permite automatizar la publicación de tu imagen de Docker cada vez que tu código pasa las pruebas. Si ya tienes el proceso de integración continua (CI) funcionando, el siguiente paso lógico es que esa imagen no solo compile, sino que llegue a tu registro de Docker Hub sin intervención manual.

¿Qué necesitas antes de configurar el CD con Docker?

Antes de tocar el archivo de GitHub Actions, necesitas preparar credenciales en Docker Hub y abrir una nueva tarea en tu flujo de trabajo.

Lo primero es generar un personal access token desde tu cuenta de Docker Hub. Entras a tu perfil, abres account settings y seleccionas la opción de crear un nuevo token. Este token funciona como una contraseña temporal que tu pipeline usará para autenticarse.

¿Por qué debo guardar el token de Docker Hub al crearlo? Porque Docker Hub solo te muestra el token completo dos veces. Si lo pierdes, tienes que generar uno nuevo desde cero.

Una vez que tengas el token, abre un nuevo issue en tu iteración. En el ejemplo, la tarea se llama establecer CD para Docker y queda asociada a la rama número 12. Tener la tarea registrada te ayuda a vincular el pull request con el issue usando la palabra clave closes.

¿Cómo se editan los secretos del repositorio en GitHub?

Los secretos son la forma segura de guardar credenciales sensibles dentro de GitHub para que tu workflow las consuma sin exponerlas en el código.

Entra a settings, abre la categoría secrets and variables y selecciona actions. Ahí dentro de secretos de repositorio creas dos entradas:

• DOCKER_HUB_USERNAME: tu nombre de usuario en Docker Hub.
• DOCKER_HUB_TOKEN: el token que acabas de generar.

Los nombres son convención, no obligación. Puedes ponerles el que más te acomode siempre y cuando los referencies igual dentro de tu archivo de GitHub Actions. Lo importante es que coincidan.

¿Qué cambios hago en el archivo de GitHub Actions?

Dentro del archivo API contactos CI CD, eliminas el paso de ls -a que solo servía para verificar la ubicación durante la fase de CI. Ya cumplió su propósito.

Después reemplazas esa sección con tres pasos clave en orden:

1. Build docker image: compila la imagen usando el image base name definido arriba.
2. Login to Docker Hub: usa los secretos DOCKER_HUB_USERNAME y DOCKER_HUB_TOKEN para autenticarte.
3. Push de la imagen: despliega la imagen ya compilada al registro con el mismo nombre base.

El orden importa: primero compilas, luego te autenticas y al final publicas. Y aquí viene lo interesante, una vez que el archivo está listo, haces commit en una nueva rama, en este caso llamada amines/12.

¿Cómo se valida que el pipeline de CI/CD funcionó?

La validación ocurre en dos lugares: en GitHub Actions y en Docker Hub. Ambos te dan señales claras de que el flujo terminó bien.

Después de crear el pull request, lo asignas a un reviewer y esperas su aprobación. En el ejemplo, Óscar aprobó el código incluso antes de que terminaran las pruebas del GitHub Action. Cuando los checks pasan, fusionas el pull request, confirmas la fusión y eliminas la rama.

¿Cómo sé que la imagen llegó a Docker Hub? Refrescas la página de tu repositorio en Docker Hub y verás un timestamp tipo hace un minuto en API contactos. Ese push lo hizo el pipeline, no tú.

En la pestaña actions puedes inspeccionar cuánto duró cada tarea. La más lenta del ejemplo fue de aproximadamente 21 segundos. Si todo aparece en verde, el CI/CD cerró el ciclo correctamente.

¿Qué ganas con automatizar el CD hacia Docker Hub?

La automatización elimina pasos manuales que se prestan a errores humanos. Tú no hiciste el push, tú no hiciste el build, y aún así tu imagen está publicada y lista para consumirse.

A partir de este punto, cada vez que agregues un nuevo método a tu API el flujo se repite solo:

• Ejecuta las pruebas definidas en CI.
• Compila la imagen de Docker si las pruebas pasan.
• Inicia sesión en Docker Hub con los secretos.
• Publica la imagen actualizada en tu registro.

Eso es cumplir con CI/CD de punta a punta dentro de GitHub Actions sin abrir una terminal extra. ¿Ya tienes tu primer pipeline corriendo? Cuéntame en los comentarios qué parte te costó más configurar.