Correr pruebas dentro de contenedores asegura entornos homogéneos y resultados confiables. Aquí verás cómo ejecutar tests con Docker tanto en local como en Jenkins, controlar tiempos con timeout, etiquetar imágenes con build number y, sobre todo, mantener el cache centralizado en el CI para producción y staging.

¿Cómo correr pruebas con Docker en local y en CI?

Partimos de un Dockerfile cuya orden por defecto es node index, pero podemos hacer override del comando para ejecutar npm test dentro del contenedor. Así garantizamos que las pruebas corren en el mismo entorno en todas partes.

¿Cómo instalar Docker y dar permisos a Jenkins?

En un script para Ubuntu se instala Docker y se aplica un ajuste clave: añadir el usuario Jenkins al grupo docker. Sin eso, solo Root puede usar Docker y Jenkins fallará al ejecutar contenedores. Luego, reiniciar Jenkins para que el cambio de grupo surta efecto. Este detalle evita horas de búsqueda en foros y errores de permisos.

• Instalar Docker siguiendo la guía del sistema operativo.
• Añadir Jenkins al grupo docker para evitar restricciones de Root.
• Reiniciar el servicio de Jenkins para activar los cambios.

¿Cómo construir la imagen y ejecutar npm test con override de comando?

Primero se construye la imagen y se etiqueta. Luego se ejecuta el contenedor sobreescribiendo el comando por defecto para correr las pruebas.

fullscreen
# Construcción de la imagen (usa -t para etiquetar)
docker build -t elbuo8/webapp2 .

# Ejecución de pruebas dentro del contenedor (override del CMD)
docker run -it elbuo-webapp npm test

• -t: define el tag de la imagen.
• docker run … npm test: reemplaza node index del Dockerfile para correr los tests.
• npm t: alias de npm test.

¿Qué rol cumple el tag, el artifact ID y el build number?

Cada ejecución en CI tiene un build number. Se usa para taggear la imagen y formar un artifact ID versionado: así el artifact queda ligado a su build number. Esto facilita trazabilidad y despliegues predecibles.

• Imagen etiquetada por build number para versionar sin ambigüedad.
• Variable de entorno para definir el artifact ID desde el inicio del pipeline.
• Mismo flujo en local y en CI para evitar sorpresas.

¿Cómo orquestar el pipeline en Jenkins con Docker?

Se usa un Jenkinsfile con pipeline declarativo. Se define un timeout de 2 minutos para los tests: si se excede, el build falla. La imagen se construye con la herramienta nativa docker.build, se guarda en una variable y las pruebas se ejecutan con docker run en foreground mediante un comando de shell.

fullscreen
// Esquema simplificado coherente con lo explicado
pipeline {
  options { timeout(time: 2, unit: 'MINUTES') }
  environment {
    // artifact ID con repo e include del build number
    ARTIFACT_ID = 'elbuo8/webapp:${BUILD_NUMBER}'
  }
  stages {
    stage('Build') {
      steps {
        script {
          docker_image = docker.build(env.ARTIFACT_ID)
        }
      }
    }
    stage('Test') {
      steps {
        // docker.run asume background; usamos shell para foreground
        sh "docker run ${docker_image.id} npm test"
      }
    }
  }
}

• timeout: controla que los tests no excedan 2 minutos.
• docker.build: etiqueta automáticamente con el valor provisto y usa el cache del agente.
• sh 'docker run …': evita el modo background de docker.run y reporta fallos de inmediato en foreground.

¿Cómo configurar el trabajo en Jenkins y por qué centralizar el cache?

Se crea un trabajo tipo Multi-Branch Pipeline, se asocia el Jenkinsfile y se ejecuta la rama (por ejemplo, master). Jenkins clona el repositorio, construye la imagen y reutiliza el cache entre builds. Esto es clave: el cache debe vivir en Jenkins/CI, no en máquinas locales.

• CI como fuente de verdad: visibilidad de builds y tests.
• Menos riesgo de tests omitidos o entornos divergentes.
• Preparación sólida para staging y producción.

¿Te quedó alguna duda sobre el uso de Docker con Jenkins o quieres compartir tu flujo de pipeline? Comenta tus retos y aprendizajes.