Integrar Jenkins con GitHub no tiene por qué ser complejo: con un webhook bien configurado y un jobfreestyle, puedes ejecutar tus tests de Node.js en cada push o pull request. Aquí verás el flujo completo, desde enlazar el repositorio por HTTPS hasta activar el trigger correcto y evitar errores comunes como olvidar el slash final del webhook.
¿Cómo integrar Jenkins con GitHub y disparar builds con webhooks?
La clave está en configurar el SCM, habilitar el trigger de GitHub y preparar los build steps para npm. Además, valida que tengas Git instalado donde corre Jenkins.
Crear un nuevo item en Jenkins: freestyle project (por ejemplo, “test sum node js”).
Marcar “This is a GitHub project” y pegar la URL del repo por HTTPS.
En Git (SCM): pegar el repositorio. Si aparece error: probablemente Git no está instalado.
Repositorio público: sin credenciales. Las credenciales se verán más adelante.
Branch specifier vacío: ejecuta en todas las ramas y también en pull requests.
En Build Triggers: activar GitHub hook trigger para que el webhook inicie el build.
¿Qué comandos ejecutar con npm y Node.js?
Prepara dos build steps con Execute shell para instalar dependencias y correr tests con mocha.
cd jenkins testnpminstall
cd jenkins testnpmtest# equivalente a: npm run test
Recuerda que cada Execute shell vuelve al workspace inicial: usa cd en cada paso.
Asegura la versión de Node.js y que npm esté en el PATH con el plugin de Jenkins: Provide Node en npm bin folder to path.
Evita depender de la versión del sistema operativo: elige la versión de Node.js desde Jenkins.
¿Cómo configurar el webhook en GitHub para Jenkins?
Sin webhook activo, GitHub no avisará a Jenkins. Configúralo en el repositorio para que cada push dispare el build automáticamente.
Verifica que el GitHub plugin esté instalado en Jenkins (viene con los plugins sugeridos).
En GitHub: Settings → Webhooks → Add webhook.
URL del webhook: http://IP:PUERTO/github-webhook/ con slash final. Usa dominio en lugar de IP si es posible.
Detalle crítico: incluye el slash final. Sin él, recibirás un 302 en GitHub y Jenkins no redirige.
Content type: dejar por defecto.
Seguridad: en producción usa secret.
Eventos: seleccionar solo push event.
Activar: en Recent deliveries busca un 200 para confirmar que llegó a Jenkins.
¿Cómo validar que Jenkins ejecuta al hacer push?
Realiza un commit y git push en el repo conectado.
En GitHub: revisa Recent deliveries con respuesta 200.
En Jenkins: refresca el dashboard, verás el build iniciado por el webhook y el log con:
Clonado del repositorio.
Detección del último commit.
Ejecución de cd jenkins test, npm install y npm test.
¿Qué errores evitar y qué buenas prácticas aplicar?
Pequeños detalles frenan la integración. Ajusta estos puntos para tener builds confiables y reproducibles.
No tener Git instalado: el SCM fallará al clonar.
Olvidar cd en cada Execute shell: cada paso regresa al workspace.
No añadir Node.js y npm al PATH: Jenkins usará la versión del sistema operativo.
No activar GitHub hook trigger: Jenkins no reaccionará a los push.
Configurar mal la URL del webhook: falta de slash final provoca 302.
Dejar el branch specifier vacío si buscas cubrir todas las ramas y PRs.
Seguridad: usar secret para el webhook en entornos productivos.
Automatización: busca auto-registrar el webhook al crear repos o jobs en tu organización.
¿Ya conectaste Jenkins con GitHub y te funcionó el webhook a la primera? Cuéntame qué parte te gustaría automatizar primero o qué detalle te dio más pelea.
