Automatizar pruebas de contenedores Docker con GitHub Actions te permite validar imágenes antes de desplegarlas a producción, integrando DevOps y CI/CD en un solo flujo. Esto es útil para desarrolladores que ya manejan Docker y quieren llevar sus pipelines al siguiente nivel sin depender de pruebas manuales.
La clave está en entender que las limitantes no son técnicas, son de creatividad. Puedes encadenar tantos pasos como necesites, segmentar por carpetas o archivos, y diseñar el flujo a tu medida.
Cómo creo un workflow de testing en GitHub Actions desde cero
Antes de tocar código, conviene partir de un archivo limpio. Las plantillas suelen requerir más correcciones que un workflow escrito desde cero, así que empezar en blanco te da control total sobre la indentación de YAML, que es donde más errores aparecen.
El primer paso es crear un nuevo flujo dentro de la carpeta de actions, separado del workflow de CI que ya existe. A este nuevo archivo lo nombras Testing en lugar de Main, y defines:
- El nombre del workflow.
- La rama que lo dispara, en este caso Main.
- El job principal, llamado docker-test.
- El agente donde corre, que será Ubuntu.
Dejar una línea en blanco entre bloques no es obligatorio, pero ayuda a que el archivo se lea mejor cuando vuelves a revisarlo semanas después [01:30].
¿Por qué falla mi YAML por un espacio? Porque YAML usa la indentación para definir jerarquía. Un espacio de más rompe la estructura y GitHub Actions no puede interpretar el archivo. Revisa visualmente las líneas guía del editor.
Qué pasos necesita un job para probar un contenedor Docker
El flujo dentro del job docker-test sigue una secuencia lógica que replica lo que harías en tu terminal local, pero automatizado. Cada paso depende del anterior y, si uno falla, el workflow se detiene.
Checkout, build y run del contenedor
El primer paso siempre es el checkout del repositorio, que extrae todos los archivos para que el agente pueda trabajar con ellos. Después viene la configuración del motor de Docker dentro de la action, lo que prepara el entorno para construir y correr imágenes.
El tercer paso es Run Docker Container, donde ejecutas docker run sobre una imagen de Alpine. Aquí agregas parámetros que mantienen al contenedor esperando un evento, haciendo su vida persistente para que no se apague de inmediato y puedas ejecutar pruebas dentro [02:45].
Ejecutar pruebas dentro del contenedor con docker exec
El paso de pruebas usa docker exec para entrar al contenedor en ejecución. Hay un detalle crítico: Alpine no incluye Bash, así que debes invocar Shell en su lugar. Si intentas usar Bash, el comando falla.
Dentro del contenedor puedes:
- Moverte a un directorio con
cd y mkdir.
- Generar un archivo de prueba con
printf, por ejemplo ejemplo.txt.
- Verificar que el archivo existe.
- Salir del contenedor al terminar.
¿Qué es docker exec? Es el comando que ejecuta instrucciones dentro de un contenedor que ya está corriendo, sin necesidad de iniciar uno nuevo. Lo usas para inspeccionar, probar o modificar el entorno en vivo.
Cómo verifico que el workflow corrió bien en GitHub Actions
Una vez que guardas los cambios y los empujas a la rama Main, GitHub Actions dispara automáticamente las ejecuciones. En la pestaña Actions verás dos workflows corriendo en paralelo: el Docker CI original y el nuevo docker-test.
Al seleccionar la ejecución de docker-test puedes expandir cada paso para ver el log detallado. El proceso típico muestra:
- Docker build configura y descarga la imagen.
- La imagen se ejecuta como contenedor, indicando que no estaba disponible localmente.
- El paso de pruebas muestra el comando solicitado y su salida.
- Aparecen los movimientos entre carpetas y la creación del archivo ejemplo.txt.
- El resultado final confirma que las pruebas pasaron [04:50].
La ejecución suele ser tan rápida que termina antes de que alcances a abrir el log. Eso es señal de que el pipeline está optimizado.
Por qué adaptar las pruebas al tipo de contenedor que uso
No todos los contenedores se prueban igual. La estrategia cambia según lo que estés desplegando, y aquí viene lo interesante: GitHub Actions no te impone un formato, tú defines qué validar.
Algunos ejemplos prácticos:
- Si despliegas una API, puedes lanzar una sentencia
curl para verificar que los endpoints responden.
- Si corres un script, replicas la ejecución dentro del contenedor como en el ejemplo anterior.
- Si trabajas con una base de datos, puedes correr queries de validación.
El punto es que cada imagen tiene su propio tipo de pruebas, y el workflow debe adaptarse a eso. Cuando confirmas que el contenedor funciona como esperas, puedes extender el mismo GitHub Action para que despliegue la imagen a la nube automáticamente.
La ganancia real es que dejas de ser tú quien prueba manualmente cada cambio. El pipeline lo hace por ti, en cada push, sin descanso. ¿Qué tipo de pruebas estás aplicando a tus contenedores hoy?
