INTEGRACIÓN TRAVISCI n8n: AUTOMATIZAR TRAVISCI CON N8N

Esta acción dispara un nuevo build en Travis CI para un repositorio y rama específicos. Es particularmente útil cuando quieres iniciar tu pipeline CI/CD basándote en eventos externos a GitHub/GitLab (validación de un cliente en tu CRM, finalización de un proceso de preparación de datos, horario planificado, etc.). Perfecto para orquestar deploys complejos donde el código está listo pero necesitas coordinación con otras herramientas de automatización antes de lanzar el build.

Parámetros clave:

• Slug: Campo de texto requerido que identifica tu repositorio en formato propietario/nombre-repo (por ejemplo, "n8n-io/n8n"). Este slug define exactamente qué proyecto Travis CI se verá afectado por la acción.
• Branch: Campo de texto requerido que especifica la rama Git en la cual deseas disparar el build (por ejemplo, "master", "develop", "feature/nueva-funcionalidad"). Travis CI ejecutará el build con la configuración definida en .travis.yml de esa rama.
• Additional Fields: Sección opcional que permite añadir parámetros avanzados como variables de entorno personalizadas, mensaje de commit, o configuraciones específicas del build mediante el botón "Add Field".

Casos de uso típicos:

• Disparar automáticamente un build de production cuando un webhook de tu sistema de ticketing indica que una release está validada por QA.
• Lanzar builds programados cada noche a las 2h para ejecutar tests de integración completos en un entorno limpio.
• Orquestar deploys multi-repositorios: cuando el Repo A termina su build exitosamente, disparar automáticamente el build del Repo B que depende de él.
• Crear workflows de self-service donde clientes internos pueden lanzar builds sin acceso directo a Travis CI, simplemente completando un formulario que alimenta n8n.

Cuándo usarlo: Utiliza esta acción cuando necesitas control programático sobre el inicio de tus builds CI/CD, independientemente del flujo habitual de push a GitHub. Especialmente potente para automatizar deploys basados en aprobaciones, calendarios o dependencias entre proyectos.

Esta acción reinicia un build Travis CI existente usando su ID único. Extremadamente útil para gestionar fallos temporales sin necesidad de hacer un nuevo commit: timeouts de red, indisponibilidad puntual de dependencias externas, o recursos insuficientes durante la ejecución inicial. Reiniciar un build preserva el contexto del commit original, garantizando consistencia en tu pipeline.

Parámetros clave:

• Build ID: Campo de texto requerido donde proporcionas el identificador numérico único del build que deseas reiniciar (por ejemplo, "587452195"). Puedes obtener este ID desde la API Get Build, desde webhooks Travis CI, o directamente desde la URL de un build en el dashboard Travis CI. Acepta valores fijos o expresiones dinámicas para workflows complejos.

Casos de uso típicos:

• Crear un workflow auto-recuperador que detecta builds fallidos por timeout, espera 5 minutos, luego los reinicia automáticamente hasta 3 intentos antes de alertar al equipo.
• Reiniciar en batch todos los builds fallidos de las últimas 24h cada mañana, filtrando solo aquellos con códigos de error específicos (network timeout, dependency unavailable).
• Implementar un sistema de aprobación manual: un build falla, envías notificación a Slack con un botón "Reintentar", el clic dispara el restart vía n8n.

Cuándo usarlo: Perfecto cuando un build ha fallado por razones externas temporales y quieres relanzar la ejecución sin modificar el código ni crear un nuevo commit. Ahorra tiempo considerable en contextos de CI/CD con dependencias de servicios externos.

Esta acción recupera una lista de múltiples builds desde Travis CI con capacidad de filtrado y paginación. Esencial para workflows de monitoreo, reporting o análisis de tendencias en tus pipelines CI/CD. Obtén hasta 100 builds (o todos si desactivas el límite) para procesarlos programáticamente en n8n.

Parámetros clave:

• Return All: Interruptor on/off opcional que, cuando está desactivado (como en la captura), permite especificar un número máximo de resultados vía el parámetro "Limit". Activarlo recupera todos los builds disponibles, ignorando el límite.
• Limit: Campo numérico que aparece cuando "Return All" está desactivado. Define el número máximo de builds a recuperar (configurado a "100" en el ejemplo). Útil para optimizar rendimiento y evitar sobrecarga de datos en workflows que solo necesitan los builds más recientes.
• Additional Fields: Sección opcional con botón "Add Field" para incluir criterios de filtrado avanzados como estado del build (passed/failed/errored), rango de fechas, repositorio específico, o branch. Potencia considerable para queries precisas.

Casos de uso típicos:

• Generar un reporte semanal automatizado: recupera todos los builds de los últimos 7 días, calcula la tasa de éxito, identifica las ramas más problemáticas y envía un resumen a Google Sheets o Notion.
• Crear un dashboard en tiempo real: cada hora, obtiene los 50 últimos builds, extrae métricas clave (duración media, tasa de fallo) y actualiza un widget en tu herramienta de monitoreo como Grafana.
• Implementar alertas inteligentes: si más de 5 builds consecutivos fallan en las últimas 2 horas, dispara una alerta crítica a PagerDuty.

Cuándo usarlo: Utiliza Get Many cuando necesitas vista de conjunto sobre tus pipelines CI/CD para análisis, reporting o detección de patrones. Combínalo con nodos de filtrado y agregación n8n para extraer insights accionables de tus datos Travis CI.

Esta acción recupera información detallada sobre un build Travis CI específico utilizando su ID único. Obtén el estado actual, duración, logs resumidos, commit asociado, rama, y todos los metadatos del build. Fundamental para workflows de notificación condicional o decisiones basadas en el resultado de un build particular.

Parámetros clave:

• Build ID: Campo de texto requerido que especifica el identificador único del build a consultar. Acepta entrada "Fixed" (valor estático) o "Expression" (valor dinámico calculado desde datos previos del workflow). En workflows complejos, típicamente usarás expresiones para extraer el Build ID desde un webhook o desde la respuesta de otra acción Travis CI.
• Additional Fields: Sección opcional con botón "Add Field" para incluir parámetros adicionales si la API Travis CI los soporta (actualmente, la captura muestra "No properties", indicando que no hay campos extra configurados).

Casos de uso típicos:

• Workflow de notificación post-build: Travis CI envía webhook a n8n cuando un build termina → n8n usa Get para recuperar detalles completos → envía mensaje Slack personalizado con estado, duración, y enlace directo al build.
• Decisión condicional: recupera estado de un build específico, si es "passed" continúa con deploy a producción, si es "failed" crea ticket Jira y notifica al equipo.
• Monitoreo de builds críticos: verifica cada 5 minutos el estado de un build de release importante, alerta inmediatamente si el estado cambia a "errored".

Cuándo usarlo: Utiliza Get cuando necesitas información precisa y completa sobre un build específico para tomar decisiones automatizadas o construir notificaciones ricas. Combínalo con If nodes en n8n para crear lógica condicional basada en el resultado del build.

Esta acción cancela un build Travis CI en curso utilizando su ID único. Extremadamente útil para optimizar recursos y reducir tiempos de feedback cuando detectas que un build ya no es necesario: commit más reciente publicado en la misma rama, tests obsoletos, o build disparado por error. Cancelar builds innecesarios libera runners Travis CI y acelera la cola de ejecución.

Parámetros clave:

• Build ID: Campo de texto requerido donde proporcionas el identificador numérico del build a cancelar. Este parámetro es crucial para dirigir precisamente la operación de cancelación al build correcto. Acepta valores estáticos o expresiones dinámicas para workflows avanzados.

Casos de uso típicos:

• Workflow de optimización de cola: cuando un nuevo commit se publica en una rama, cancela automáticamente todos los builds anteriores en curso de esa misma rama (ya que están obsoletos).
• Cancelación manual via interfaz self-service: crear un formulario donde desarrolladores pueden seleccionar un build de una lista y cancelarlo sin acceso directo a Travis CI.
• Gestión de recursos: si detectas que más de 10 builds están en cola, cancela los builds más antiguos de branches de feature (no prioritarias) para priorizar builds de master/develop.
• Detección de errores tempranos: si un build falla en sus primeros 2 minutos (fase de setup), cancela automáticamente en vez de esperar la ejecución completa.

Cuándo usarlo: Utiliza Cancel cuando necesitas interrumpir programáticamente builds en ejecución para optimizar recursos, reducir tiempos de espera o gestionar errores detectados temprano. Particularmente potente combinado con Get Many para identificar builds a anular basados en criterios específicos (antigüedad, rama, estado).