Recursos · Integración n8n

Integración Currents n8nAutomatiza Currents con n8n.

¿Cuánto tiempo pierde tu equipo mirando el panel de una suite de tests? La integración Currents n8n existe para que deje de mirarlo: 22 operaciones repartidas en 8 recursos, de los runs a las firmas de test, y un trigger que escucha 4 eventos de run y salta en segundos.

Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth

Por qué automatizar

¿Qué permite de verdad la integración Currents n8n?

Currents guarda el resultado de tus runs de test. n8n es el motor de flujos que reacciona a ellos. Juntos, el nodo Currents pone 22 operaciones sobre la mesa, repartidas en 8 recursos: runs, tests, ficheros de spec, resultados de test, proyectos, insights, acciones y firmas. El Currents Trigger añade 4 eventos de run que llegan por webhook, o sea por una URL que Currents llama en cuanto ocurre algo.

Empecemos por donde duele el presupuesto: la CI. Cuando una pull request recibe tres pushes seguidos, los runs anteriores ya no sirven de nada y siguen ocupando máquinas. Cancel a run by GitHub CI acepta directamente el identificador del run de GitHub Actions y su número de intento, así que el flujo corta el run correcto sin buscar nada en Currents. Para los casos en los que sí conoces el identificador interno, Cancel a run hace lo mismo con un solo campo. Si todavía estás decidiendo dónde alojar tu propio n8n junto a la CI, la Reseña n8n entra en ese detalle.

Luego está el aviso, que es lo que casi todo el mundo monta el primer día. El trigger escucha RUN_FINISH, un paso Get a run recupera la ficha completa y el mensaje aterriza en Slack con la rama y el estado. Nadie recarga un panel durante una ventana de despliegue.

El tercer bloque es el que zanja discusiones. Generate a signature convierte una ruta de spec y un título de test en un identificador estable, y Get test results devuelve el histórico de ese test exacto entre dos fechas, filtrable por rama. Con eso, una base de Airtable o una hoja de Google Sheets deja de ser una lista de quejas y pasa a ser un registro que se puede ordenar.

Todo lo que la API de Currents ofrezca más allá de estas 22 operaciones del catálogo se alcanza con el nodo HTTP Request, que llama a cualquier endpoint reutilizando el mismo credential mediante la autenticación predefinida. Es la salida estándar de n8n para ese caso.

Un consejo de orden, para terminar: monta primero un solo evento y una sola operación, compruébalo con un run real y solo después añade el resto. Los flujos de calidad que sobreviven son los que crecen así. El Curso n8n cubre las expresiones y el control de errores, que es donde se cae un flujo de tests cuando llega una semana mala.

Conexión

¿Cómo se conecta Currents con n8n?

  1. 01

    Crea el credential una sola vez

    Abre el menú Credentials de n8n y añade un credential de Currents. Un credential es un juego de identificadores que se guarda una vez y lo reutilizan todos los flujos de la instancia, así que el token no se pega a mano dentro de un nodo. Los campos a rellenar son los que muestra el formulario al abrirlo. Guardado el credential, queda disponible tanto para el nodo Currents como para el Currents Trigger.

  2. 02

    Selecciónalo en el nodo

    Coloca un nodo Currents en el lienzo. Su desplegable de credentials muestra los que ya existen en la instancia, y ahí eliges el que acabas de guardar. La misma lista aparece en el Currents Trigger, de modo que un único credential cubre la parte que lee y la parte que escucha. En n8n Cloud y en una instancia autoalojada el comportamiento es el mismo.

  3. 03

    Compruébalo con una lectura

    Pon el recurso en Project, la operación en Get many projects y ejecuta el nodo. No pide ningún parámetro obligatorio, así que una respuesta correcta demuestra una sola cosa: el credential funciona. De paso obtienes los identificadores de proyecto que espera el resource locator Project en casi todas las demás operaciones, elegidos de la lista o pasados como expresión del tipo {{ $json.campo }}.

Disparadores

¿Qué arranca un flujo desde Currents ?

Currents Trigger es el nodo que arranca un workflow cuando algo ocurre en Currents. Escucha 4 eventos, listados abajo por familia. Eliges uno o varios, activas el workflow y n8n registra el webhook (la URL que Currents llama) en tu cuenta.

Lo que ves en n8n

Todos los eventos, por familia

Una fila por objeto, un chip por acción. El evento que marcas en el nodo se escribe objeto.acción; pasa el cursor por un chip para leer cuándo se dispara.

RUN_CANCELED.*1
  • RUN_CANCELED.
    • RUN_CANCELED
RUN_FINISH.*1
  • RUN_FINISH.
    • RUN_FINISH
RUN_START.*1
  • RUN_START.
    • RUN_START
RUN_TIMEOUT.*1
  • RUN_TIMEOUT.
    • RUN_TIMEOUT

Notas de configuración

01Configure the Currents TriggerEl trigger va por la versión 1 y funciona por eventos: marcas lo que debe despertar el flujo, sin ninguna noción de intervalo.

El trigger va por la versión 1 y funciona por eventos: marcas lo que debe despertar el flujo, sin ninguna noción de intervalo.

Parámetros clave

  • Project: resource locator obligatorio que limita el trigger a un proyecto de Currents, elegido de la lista o indicado por identificador. Los eventos de otros proyectos no llegan a este flujo.
  • Events: la lista de eventos de run a los que te suscribes. Este trigger no tiene opción comodín, así que cada evento se marca de forma explícita, y añadir uno más tarde obliga a reactivar el flujo.
Cuándo usarlo
siempre que el flujo deba reaccionar a un run en lugar de ir a buscarlo. Currents llama a la URL de webhook de n8n, registrada al activar, y el evento llega en segundos.
02Run StartedRUN_START salta cuando arranca un run nuevo. Es la señal más temprana que envía Currents, la que sirve para todo lo que debe estar listo antes de que exista un resultado.

RUN_START salta cuando arranca un run nuevo. Es la señal más temprana que envía Currents, la que sirve para todo lo que debe estar listo antes de que exista un resultado.

Casos de uso
una línea en el canal de builds cuando arranca la suite nocturna, para que una noche en silencio se note enseguida. O un flujo de seguimiento que apunta la hora de inicio, espera el evento de fin correspondiente y calcula cuánto tardó de verdad la suite, rama por rama.
Cuándo usarlo
solo cuando algo posterior necesita de verdad el arranque, porque en un repositorio activo este evento salta en cada push. El parámetro Project acota ese volumen a un solo proyecto, que es media batalla ganada antes de escribir ningún filtro, y el evento de fin ya basta en la mayoría de los casos.
03Run FinishedRUN_FINISH salta cuando un run termina. En ese momento Currents ya tiene la foto completa, y por eso la mayoría de los flujos cuelgan de este único evento.

RUN_FINISH salta cuando un run termina. En ese momento Currents ya tiene la foto completa, y por eso la mayoría de los flujos cuelgan de este único evento.

Casos de uso
recuperar el run con Get a run y bifurcar según su estado, de forma que un run en verde no diga nada y uno en rojo abra un hilo con el nombre de la rama. El mismo evento alimenta bien un resumen diario: se juntan los runs terminados y se escribe una fila por run en lugar de un mensaje por fallo.
Cuándo usarlo
para informes y avisos, todo lo que necesita resultados y no intenciones. Combínalo con la cancelación y el timeout si el informe debe cuadrar con todos los runs lanzados.
04Run Canceled and Run TimeoutDos eventos cubren los runs que acaban sin veredicto. RUN_CANCELED salta cuando alguien cancela un run a mano, y RUN_TIMEOUT cuando un run supera su límite de tiempo.

Dos eventos cubren los runs que acaban sin veredicto. RUN_CANCELED salta cuando alguien cancela un run a mano, y RUN_TIMEOUT cuando un run supera su límite de tiempo.

Casos de uso
un timeout suele señalar a la infraestructura antes que al código, así que manda RUN_TIMEOUT a quien lleva las máquinas de CI, con el identificador del run dentro. Una cancelación suele ser deliberada y con una traza discreta sobra. Comparar ambos volúmenes a lo largo de una semana dice bastante rápido si la suite se está ralentizando o si el equipo pierde la paciencia.
Cuándo usarlo
junto al evento de fin, cuando un informe tiene que cuadrar con todos los runs que empezaron. Los dos se marcan en Events igual que el resto y se quedan dentro del proyecto fijado en Project.
Acciones

¿Qué sabe hacer el nodo Currents dentro de un flujo?

El nodo Currents expone 22 operaciones en 8 recursos. Para cada una: el nodo tal como lo configuras en n8n, los campos obligatorios y nuestras notas de campo.

Matriz recursos × operaciones
RecursoCreateGetGet ManyUpdateDeleteCancelCancel by GitHub CIDisableEnableFindGenerateGet InsightsReset
Action
Instance
Project
Run
Signature
Spec File
Test
Test Result

Action

7 operaciones
01

Create an action

action.create

Lo que ves en n8n

Notas y casos de uso

Las reglas de cuarentena, salto y etiquetado viven en Currents como acciones, y esta operación crea una desde el flujo en vez de desde la interfaz.

Parámetros clave

  • Name: el nombre de la regla, de 1 a 255 caracteres.
  • Action Type: quarantine, skip o tag, lo que le ocurre a los tests afectados.
  • Matcher Type y Matcher Value: cómo localiza la regla sus tests, por ruta de spec, por título o por firma, y el valor a comparar.
  • Expires After: fecha en formato ISO 8601 a partir de la cual la regla deja de aplicarse.
Casos de uso
aislar un test que ha caído tres noches seguidas, con caducidad corta para obligar a retomarlo.
02

Delete an action

action.delete

Lo que ves en n8n

Notas y casos de uso

Aquí borrar significa archivar: la regla deja de aplicarse y se queda en el historial del proyecto.

Parámetros clave

  • Action ID: el identificador de la acción a archivar, normalmente heredado de Get many actions en el mismo flujo.
Casos de uso
una limpieza mensual que lista las acciones del proyecto, conserva las que siguen atadas a un ticket abierto y archiva el resto. El conjunto de reglas se mantiene legible para quien entre en el equipo después.
03

Disable an action

action.disable

Lo que ves en n8n

Notas y casos de uso

Una pausa, no un final: desactivar deja la acción inactiva y lista para volver cuando haga falta.

Parámetros clave

  • Action ID: el identificador de la acción que se desactiva.
Casos de uso
antes de una pasada de regresión completa sobre una release candidate, apagar las cuarentenas para que la suite corra en condiciones reales. El informe muestra entonces el número de fallos verdadero y no uno filtrado.
04

Enable an action

action.enable

Lo que ves en n8n

Notas y casos de uso

La otra mitad de cualquier flujo que desactive una regla, y una sola llamada.

Parámetros clave

  • Action ID: el identificador de la acción desactivada que vuelve a activarse.
Casos de uso
el último paso de un flujo de release, donde las cuarentenas apagadas para la regresión se encienden de nuevo una vez aprobada la candidata. La siguiente rama de trabajo no arrastra tests inestables ya conocidos.
05

Get an action

action.get

Lo que ves en n8n

Notas y casos de uso

Leer antes de tocar. Esta operación devuelve una acción a partir de su identificador, que es lo que permite decidir en vez de suponer.

Parámetros clave

  • Action ID: el identificador de la acción que se consulta.
Casos de uso
una rama de mantenimiento que lee la acción citada en un ticket, mira su fecha de caducidad y solo entonces elige: prolongarla con Update an action o archivarla. Leer primero también deja el flujo seguro para volver a lanzarlo.
06

Get many actions

action.getAll

Lo que ves en n8n

Notas y casos de uso

El inventario de reglas de un proyecto empieza en esta operación, y con él cualquier auditoría.

Parámetros clave

  • Project: el resource locator que limita la lista a un proyecto.
  • Search: busca acciones por nombre, con un máximo de 100 caracteres.
  • Status: conserva solo los estados marcados, entre active, archived, disabled y expired.
Casos de uso
un resumen semanal de las cuarentenas en active, para que un test aparcado durante un sprint no siga aparcado un trimestre.
07

Update an action

action.update

Lo que ves en n8n

Notas y casos de uso

Cambiar el nombre o mover la fecha de caducidad no exige recrear nada ni perder el identificador.

Parámetros clave

  • Action ID: el identificador de la acción que se modifica.
  • Name, Description y Expires After: los tres campos de actualización, que se envían solo si los añades. Tocar la fecha deja el nombre intacto.
Casos de uso
alargar una cuarentena un sprint más y dejar la referencia del ticket escrita en la descripción de paso.

Instance

1 operación
08

Get an instance

instance.get

Lo que ves en n8n

Notas y casos de uso

Una instancia es la ejecución de un fichero de spec dentro de un run, y esta operación la devuelve con el resultado completo de sus tests.

Parámetros clave

  • Instance ID: el identificador de la instancia de ejecución que se consulta.
Casos de uso
cuando un aviso de fallo nombra un fichero, esta llamada convierte ese nombre en detalle. El mensaje que recibe el equipo lleva los títulos de los tests caídos, no un enlace que alguien tendrá que abrir.

Project

3 operaciones
09

Get a project

project.get

Lo que ves en n8n

Notas y casos de uso

Un proyecto leído por su identificador, con el contexto que rodea a las cifras.

Parámetros clave

  • Project: el resource locator, elegido de la lista o indicado por identificador.
Casos de uso
un generador de informes que arranca leyendo el proyecto para que el documento lleve un nombre real y no un identificador en crudo. Importa en cuanto el resumen sale del equipo técnico y llega a alguien que no abre Currents nunca.
10

Get many projects

project.getAll

Lo que ves en n8n

Notas y casos de uso

Sin parámetros obligatorios: por eso suele abrir el flujo, a modo de prueba rápida del credential.

Parámetros clave

  • Limit: el número máximo de proyectos devueltos, útil cuando el flujo solo necesita unos pocos para cruzar datos.
Casos de uso
un flujo programado que recorre todos los proyectos y genera un informe de insights por cada uno. Un repositorio nuevo queda cubierto el día que se crea, sin que nadie tenga que acordarse.
11

Get project insights

project.getInsights

Lo que ves en n8n

Notas y casos de uso

Métricas sobre una ventana de fechas y no sobre un run suelto: es la vista donde se ve una tendencia.

Parámetros clave

  • Project, Date Start y Date End: los tres obligatorios, las fechas en formato ISO 8601.
  • Resolution: 1h, 1d o 1w, el grano de la serie.
  • Branches, Tags, Groups y Git Authors: filtros separados por comas para estrechar la ventana.
Casos de uso
el repaso de los lunes, con resolución 1d y solo sobre la rama principal.

Run

7 operaciones
12

Cancel a run

run.cancel

Lo que ves en n8n

Notas y casos de uso

Detener un run en marcha cuesta un identificador y nada más.

Parámetros clave

  • Run ID: el identificador del run que se cancela, normalmente el que localizó un paso anterior.
Casos de uso
un flujo que vigila una rama larga y cancela el run en curso en cuanto se sube un revert, porque los resultados en camino describen código que ya no existe. Cancelar de forma explícita también produce un evento limpio en lugar de un timeout más tarde.
13

Cancel a run by GitHub CI

run.cancelGithub

Lo que ves en n8n

Notas y casos de uso

Los identificadores de GitHub Actions valen tal cual, sin buscar antes nada del lado de Currents.

Parámetros clave

  • GitHub Run ID y GitHub Run Attempt: ambos obligatorios, tomados del run de Actions y de su número de intento.
  • Project ID y CI Build ID: acotaciones opcionales, cuando un mismo run de GitHub alimenta varios proyectos o varias builds.
Casos de uso
un webhook disparado por un job de Actions cancelado, que cierra el run de Currents en el mismo movimiento.
14

Delete a run

run.delete

Lo que ves en n8n

Notas y casos de uso

Borrado sin vuelta atrás, y se lleva por delante los datos asociados al run.

Parámetros clave

  • Run ID: el identificador del run que se elimina.
Casos de uso
limpiar los runs que dejó un job de CI mal configurado apuntando al proyecto equivocado. Dejarlos ahí desviaría cualquier métrica de inestabilidad después. Conviene ponerle delante un paso de aprobación manual, porque nada de esto se deshace.
15

Find a run

run.find

Lo que ves en n8n

Notas y casos de uso

Localizar un run cuando no tienes su identificador a mano: para eso está esta operación.

Parámetros clave

  • Project: el resource locator que enmarca la búsqueda.
  • Branch, CI Build ID y Tags: los filtros que señalan el run que buscas, por nombre de rama de git, por build de CI o por etiqueta.
Casos de uso
un comando de chat donde alguien escribe el nombre de una rama y recibe el estado del run que le corresponde.
16

Get a run

run.get

Lo que ves en n8n

Notas y casos de uso

El nodo que casi siempre va detrás del trigger: con el identificador en la mano, devuelve el run entero.

Parámetros clave

  • Run ID: el identificador del run que se lee.
Casos de uso
el segundo paso de un flujo de aviso, entre el trigger y el mensaje, para que la alerta lleve la rama y el desenlace en lugar de anunciar que algo terminó en algún sitio.
17

Get many runs

run.getAll

Lo que ves en n8n

Notas y casos de uso

La única operación que lee un tramo entero de histórico de una vez, y por eso sostiene los flujos de informe.

Parámetros clave

  • Project: obligatorio, y Limit pone techo al número de runs devueltos.
  • Status y Completion State: dos ejes distintos, uno sobre PASSED o FAILED, el otro sobre COMPLETE, CANCELED, TIMEOUT o IN_PROGRESS.
  • Starting After y Ending Before: los cursores que tomas de una respuesta anterior para recorrer un histórico largo.
  • Tags con Tag Operator: AND exige todas las etiquetas, OR se conforma con una.
Casos de uso
la exportación semanal de los runs fallidos en la rama de release.
18

Reset a run

run.reset

Lo que ves en n8n

Notas y casos de uso

Repetir las specs que fallaron, sin relanzar la suite entera ni tener que esperar a que llegue otro push.

Parámetros clave

  • Run ID: el run cuyas specs fallidas se vuelven a ejecutar.
  • Machine IDs: una lista de identificadores de máquina separados por comas, de 1 a 63, que decide cómo se reparte la repetición.
  • Batched Orchestration: una opción que pasa la repetición a orquestación por lotes.
Casos de uso
un único reintento automático tras un timeout, para que un tropiezo de infraestructura no acabe en build roja relanzada a mano.

Signature

1 operación
19

Generate a signature

signature.generate

Lo que ves en n8n

Notas y casos de uso

Una firma identifica un test de forma estable entre runs, y esta operación la fabrica.

Parámetros clave

  • Project: el resource locator al que pertenece el test.
  • Spec File Path: la ruta completa del fichero de spec.
  • Test Title: el título del test, con los bloques describe anidados unidos por el separador > .
Casos de uso
el puente entre un fallo y su histórico, ya que la firma que sale de aquí es lo que esperan Get test results y una acción basada en firma.

Spec File

1 operación
20

Get many spec files

specFile.getAll

Lo que ves en n8n

Notas y casos de uso

Métricas agregadas por fichero de spec sobre un periodo, para responder a una pregunta sin rodeos: qué ficheros salen más caros.

Parámetros clave

  • Project, Date Start y Date End: la ventana obligatoria, fechas en formato ISO 8601.
  • Order By con Sort Direction: ordena por avgDuration, failureRate, flakeRate o timeoutRate, de forma ascendente o descendente.
  • Include Failed in Duration: decide si las ejecuciones fallidas cuentan en la duración.
  • Page: el número de página, empezando en 0.
Casos de uso
la lista mensual de ficheros lentos que conviene partir.

Test

1 operación
21

Get many tests

test.getAll

Lo que ves en n8n

Notas y casos de uso

La misma idea un nivel más abajo: el test en lugar del fichero, que es donde se aprecia la inestabilidad.

Parámetros clave

  • Project, Date Start y Date End: la ventana obligatoria.
  • Order By: flakiness, failures, duration y las variantes de impacto, que pesan una tasa por su número de ejecuciones.
  • Minimum Executions: descarta los tests que se han ejecutado demasiado poco como para que su tasa signifique algo.
  • Test State: conserva solo failed, passed, pending o skipped.
Casos de uso
el ranking de tests inestables que abre la revisión de calidad.

Test Result

1 operación
22

Get test results

testResult.getAll

Lo que ves en n8n

Notas y casos de uso

El histórico de un solo test, ejecución a ejecución, que es la vista que distingue un test roto de un test con mala suerte.

Parámetros clave

  • Test Signature: obligatoria, la genera Generate a signature a partir del proyecto, la ruta del fichero de spec y el título del test.
  • Date Start y Date End: la ventana obligatoria, en formato ISO 8601.
  • Status y Branches: estrechan el histórico a los estados y las ramas que te interesan.
Casos de uso
demostrar que un test solo cae en una rama antes de que alguien lo reescriba entero.
Necesitas ayuda

¿Necesitas ayuda para automatizar Currents con n8n?

El equipo te responde directamente.

Cada mensaje lo lee una persona.

FAQ

Currents y n8n, las preguntas que vienen después

01¿La integración Currents n8n es gratis?
Sí, por el lado de n8n. El nodo Currents y el Currents Trigger vienen incluidos con n8n, así que no hay nada que instalar ni ningún coste añadido, tanto en n8n Cloud como en una instancia autoalojada con la Community Edition bajo licencia Sustainable Use. Un flujo construido en una corre igual en la otra, de modo que puedes probar en Cloud y mover luego el mismo flujo a tu propia instalación con Docker. Lo que cueste una cuenta de Currents es otra historia, depende del plan que tengas con ellos y conviene confirmarlo directamente con Currents.
02¿Qué credentials hacen falta para conectar Currents con n8n?
Uno solo: un credential de Currents creado en el menú Credentials de tu instancia. El nodo Currents y el Currents Trigger leen de esa misma entrada, así que con un credential cubres las 22 operaciones y los 4 eventos del trigger. Una vez guardado aparece en el desplegable de cada nodo Currents que añadas, y el token no se copia a mano dentro de ningún flujo. El nodo no ofrece selector de autenticación, de modo que no hay método que elegir. Pruébalo con Get many projects, que no pide ningún parámetro obligatorio, antes de construir nada encima.
03¿Qué límites tiene el nodo Currents en n8n?
Hay dos cosas que conviene prever. Primero la paginación: las operaciones de lista aceptan un Limit, Get many runs y Get test results exponen los cursores Starting After y Ending Before que tomas de la respuesta anterior, y Get many spec files y Get many tests paginan con un número de Page que empieza en 0. Un histórico largo pide un bucle, no una sola llamada. Segundo, todo lo que la API de Currents ofrezca más allá de estas 22 operaciones del catálogo pasa por el nodo HTTP Request, que llega a cualquier endpoint reutilizando el mismo credential con la autenticación predefinida.
04¿El Currents Trigger reacciona en tiempo real?
Sí. El trigger funciona por webhook, es decir por una URL que Currents llama en cuanto ocurre algo, así que el evento llega en segundos y n8n nunca va preguntando a la API cómo van los runs. Esa URL queda registrada en Currents al activar el flujo, y por eso un flujo en borrador no recibe nada. El trigger se limita a un proyecto mediante su parámetro Project y a los eventos marcados en Events. No hay opción comodín, de modo que cada uno de los 4 eventos que te interesen se marca de forma explícita antes de activar.
05¿n8n o Make para Currents?
Depende del alojamiento y del modelo de coste. Make lo aloja Make, sin opción de autoalojamiento, y factura por operación: previsible, aunque sube con el volumen. n8n corre en Cloud o en tu propio servidor con Docker o npm, y el flujo es idéntico en ambos casos, así que los datos de test que prefieras mantener dentro de tu red se quedan ahí. El nodo Currents cubre las mismas 22 operaciones en cualquiera de las dos. Si tu automatización se limita a leer métricas a una hora fija, las dos sirven. Si vive dentro de una cadena de CI que ya autoalojas, tenerlo todo junto suele salir mejor.
Hack'celeration Lab

Recibe nuestros tips de integración cada semana.

Sin spam. Cancela cuando quieras.