Ressources · Intégration n8n

Intégration Currents n8nAutomatiser Currents avec n8n.

Ta suite de tests sait déjà quels fichiers te coûtent le plus de temps. L'intégration Currents n8n sert à en faire quelque chose : 22 opérations réparties sur 8 ressources, des runs aux signatures de test, et un trigger qui écoute 4 événements de run et se déclenche en quelques secondes.

Tester l'intégration Currents sur n8nVoir les 22 opérations

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

Que permet vraiment l'intégration Currents n8n ?

Currents collecte les résultats de tes runs de test. n8n est le moteur de workflow qui réagit à ces résultats. Ensemble, le nœud Currents met 22 opérations à disposition, réparties sur 8 ressources : runs, tests, fichiers de spec, résultats de test, projets, insights, actions et signatures. Le Currents Trigger ajoute 4 événements de run livrés par webhook, c'est-à-dire une URL que Currents appelle dès qu'il se passe quelque chose.

Le premier chantier, c'est presque toujours le tri des tests instables. Get many tests renvoie les métriques agrégées d'un projet sur une fenêtre de dates, triées par instabilité. Tu prends le pire, tu le passes à Generate a signature qui transforme un chemin de fichier et un titre de test en identifiant stable, puis à Create an action avec un type quarantine. Le test arrête de casser les builds pendant qu'une personne le répare. Une date d'expiration sur l'action, et la quarantaine ne devient pas permanente par oubli.

Deuxième usage, plus calme : le rapport. Get project insights et Get many spec files travaillent tous les deux sur une période et acceptent les mêmes filtres de branche, de tag et d'auteur git. De quoi alimenter chaque lundi matin un onglet Google Sheets que l'équipe produit lit sans jamais ouvrir Currents.

Troisième usage, le plus urgent des trois : l'alerte. Le trigger écoute RUN_TIMEOUT, un run qui dépasse son délai remonte tout de suite, et le message part vers Slack en journée ou vers Telegram pour l'astreinte de nuit. Un timeout pointe rarement le code, il pointe la machine, donc autant prévenir la bonne personne.

Pour tout ce que l'API Currents propose au-delà de ces 22 opérations du catalogue, le nœud HTTP Request appelle n'importe quel endpoint en réutilisant le même credential via l'authentification prédéfinie. C'est la porte de sortie normale dans n8n, pas un bricolage.

Si la question de fond reste la plateforme elle-même, l'Avis n8n traite l'hébergement et le modèle de coût. Et si le blocage est plutôt sur les expressions et la gestion d'erreur, les deux choses qui décident de la survie d'un workflow de test, la Formation n8n passe dessus en détail.

Connexion

Comment connecter Currents à n8n ?

  1. 01

    Créer le credential une seule fois

    Dans n8n, ouvre le menu Credentials et ajoute un credential Currents. Un credential, c'est un jeu d'identifiants enregistré une fois et réutilisé par tous les workflows de l'instance : le jeton ne se colle jamais à la main dans un nœud. Les champs à remplir sont ceux que le formulaire affiche à l'ouverture. Une fois enregistré, le credential devient disponible pour le nœud Currents comme pour le Currents Trigger.

  2. 02

    Le sélectionner dans le nœud

    Pose un nœud Currents sur le canevas. Sa liste déroulante de credentials affiche ceux déjà enregistrés sur l'instance, tu choisis celui que tu viens de créer. La même liste apparaît sur le Currents Trigger : un seul credential couvre donc le côté lecture et le côté écoute de tes workflows. Le comportement est identique sur n8n Cloud et sur une instance auto-hébergée.

  3. 03

    Vérifier avec une lecture

    Mets la ressource sur Project, l'opération sur Get many projects, puis exécute le nœud. Elle ne demande aucun paramètre obligatoire, donc un résultat qui revient prouve exactement une chose : le credential est valide. Tu récupères au passage les identifiants de projet qu'attend le resource locator Project sur la plupart des autres opérations, à choisir dans la liste ou à passer en expression du type {{ $json.champ }}.

Déclencheurs

Qu'est-ce qui déclenche un workflow depuis Currents ?

Currents Trigger est le nœud qui démarre un workflow quand quelque chose se passe dans Currents. Il écoute 4 événements, listés ci-dessous par famille. Tu en choisis un ou plusieurs, tu actives le workflow : n8n enregistre le webhook (l'URL que Currents appelle) sur ton compte.

Ce que tu vois dans n8n

Tous les événements, par famille

Une ligne par objet, une puce par action. L'événement à cocher dans le nœud s'écrit objet.action ; survole une puce pour lire quand il se déclenche.

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

Notes de configuration

01Configure the Currents TriggerLe trigger est en version 1 et fonctionne par événements : tu coches ce qui doit réveiller le workflow, aucune notion d'intervalle ici.

Le trigger est en version 1 et fonctionne par événements : tu coches ce qui doit réveiller le workflow, aucune notion d'intervalle ici.

Paramètres clés

  • Project : un resource locator obligatoire qui limite le trigger à un projet Currents, choisi dans la liste ou donné par identifiant. Les événements des autres projets n'atteignent jamais ce workflow.
  • Events : la liste des événements de run auxquels s'abonner. Ce trigger n'a pas d'option attrape-tout, chaque événement voulu se coche donc explicitement, et en ajouter un plus tard suppose de rouvrir puis de réactiver le workflow.
Quand l'utiliser
dès que le workflow doit réagir à un run plutôt que d'aller le chercher. Currents appelle l'URL de webhook n8n, enregistrée à l'activation, et l'événement arrive en quelques secondes.
02Run StartedRUN_START part au démarrage d'un nouveau run. C'est le signal le plus précoce que Currents envoie, donc celui qui sert à tout ce qui doit être en place avant qu'un résultat existe.

RUN_START part au démarrage d'un nouveau run. C'est le signal le plus précoce que Currents envoie, donc celui qui sert à tout ce qui doit être en place avant qu'un résultat existe.

Cas d'usage
une ligne dans le canal build quand la suite nocturne démarre, pour qu'une nuit silencieuse se remarque tout de suite. Ou un workflow de suivi qui note l'heure de départ, attend l'événement de fin correspondant et calcule la durée réelle de la suite, branche par branche.
Quand l'utiliser
uniquement si quelque chose en aval a vraiment besoin du démarrage, parce que sur un dépôt actif cet événement part à chaque push. Le paramètre Project borne déjà ce volume à un seul projet, ce qui règle une bonne partie de la question avant même d'écrire un filtre, et l'événement de fin suffit dans la plupart des cas.
03Run FinishedRUN_FINISH part quand un run se termine. À ce moment-là, Currents dispose de l'image complète du run, ce qui explique que la plupart des workflows s'accrochent à ce seul événement.

RUN_FINISH part quand un run se termine. À ce moment-là, Currents dispose de l'image complète du run, ce qui explique que la plupart des workflows s'accrochent à ce seul événement.

Cas d'usage
récupérer le run avec Get a run et router selon son statut, pour qu'un run vert reste silencieux et qu'un run rouge ouvre un fil avec le nom de la branche. Le même événement alimente très bien un récapitulatif quotidien : on collecte les runs terminés, on écrit une ligne par run au lieu d'un message par échec.
Quand l'utiliser
pour le reporting, la notification, tout ce qui a besoin de résultats et pas d'intentions. À combiner avec l'annulation et le timeout si le rapport doit rendre compte de tous les runs lancés.
04Run Canceled and Run TimeoutDeux événements couvrent les runs qui finissent sans verdict. RUN_CANCELED part quand quelqu'un annule un run à la main, RUN_TIMEOUT quand un run dépasse sa limite de temps.

Deux événements couvrent les runs qui finissent sans verdict. RUN_CANCELED part quand quelqu'un annule un run à la main, RUN_TIMEOUT quand un run dépasse sa limite de temps.

Cas d'usage
un timeout désigne plus souvent l'infrastructure que le code, donc envoie RUN_TIMEOUT vers l'équipe qui tient les machines de CI, avec l'identifiant du run. Une annulation est en général volontaire, une simple trace suffit. Comparer les deux volumes sur une semaine dit assez vite si la suite ralentit ou si l'équipe s'impatiente.
Quand l'utiliser
avec l'événement de fin, quand un rapport doit réconcilier tous les runs démarrés. Les deux se cochent dans Events comme les autres et restent limités au projet choisi dans Project, donc une instance n8n partagée entre plusieurs équipes ne remonte jamais les runs des dépôts voisins.
Actions

Que sait faire le nœud Currents dans un workflow ?

Le nœud Currents expose 22 opérations sur 8 ressources. Pour chacune : le nœud tel que tu le configures dans n8n, les champs obligatoires, et nos notes de terrain.

Matrice ressources × opérations
RessourceCreateGetGet ManyUpdateDeleteCancelCancel by GitHub CIDisableEnableFindGenerateGet InsightsReset
Action✓✓✓✓✓✓✓
Instance✓
Project✓✓✓
Run✓✓✓✓✓✓✓
Signature✓
Spec File✓
Test✓
Test Result✓

Action

7 opérations
01

Create an action

action.create

Ce que tu vois dans n8n

Notes & cas d'usage

Une action, dans Currents, c'est une règle qui met un test en quarantaine, le saute ou le tague. Cette opération en crée une depuis un workflow.

Paramètres clés

  • Name : le libellé de la règle, de 1 à 255 caractères.
  • Action Type : quarantine, skip ou tag, ce qui arrive aux tests concernés.
  • Matcher Type et Matcher Value : comment la règle repère ses tests, par chemin de spec, par titre ou par signature, et la valeur à comparer.
  • Expires After : une date au format ISO 8601 après laquelle la règle cesse de s'appliquer.
Cas d'usage
mettre en quarantaine un test tombé trois nuits de suite, avec une expiration courte pour forcer la reprise.
02

Delete an action

action.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Archiver plutôt que supprimer : la règle cesse de s'appliquer et reste au dossier du projet.

Paramètres clés

  • Action ID : l'identifiant de l'action à archiver, en général repris de Get many actions dans le même workflow.
Cas d'usage
un ménage mensuel qui liste les actions d'un projet, garde celles encore rattachées à un ticket ouvert et archive le reste. Le jeu de règles reste lisible pour la personne qui arrive au trimestre suivant.
03

Disable an action

action.disable

Ce que tu vois dans n8n

Notes & cas d'usage

Mettre une règle en pause sans rien changer d'autre : la désactivation suspend une action active et la laisse prête à revenir.

Paramètres clés

  • Action ID : l'identifiant de l'action à désactiver.
Cas d'usage
avant une passe de non-régression complète sur une release candidate, couper les quarantaines pour que la suite tourne comme en conditions réelles. Le rapport montre alors le vrai nombre d'échecs, pas un décompte filtré.
04

Enable an action

action.enable

Ce que tu vois dans n8n

Notes & cas d'usage

Le pendant exact de la désactivation, et la fin logique de tout workflow qui en désactive une.

Paramètres clés

  • Action ID : l'identifiant de l'action désactivée à réactiver.
Cas d'usage
la dernière étape d'un workflow de release, où les quarantaines coupées pour la passe de non-régression se rallument une fois la candidate validée. La branche de feature suivante ne se traîne pas des tests instables déjà connus.
05

Get an action

action.get

Ce que tu vois dans n8n

Notes & cas d'usage

Lire une règle avant de la modifier évite les mauvaises surprises. Cette opération renvoie une action par son identifiant.

Paramètres clés

  • Action ID : l'identifiant de l'action à lire.
Cas d'usage
une branche de workflow de maintenance qui lit l'action citée dans un ticket, regarde sa date d'expiration et décide seulement après : prolonger avec Update an action, ou archiver. Lire d'abord rend aussi le workflow rejouable sans dégât.
06

Get many actions

action.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

L'inventaire des règles d'un projet passe par là, et c'est le point de départ de tout audit.

Paramètres clés

  • Project : le resource locator qui limite la liste à un projet.
  • Search : recherche les actions par nom, sur 100 caractères au maximum.
  • Status : ne garde que les états cochés, parmi active, archived, disabled et expired.
Cas d'usage
un récapitulatif hebdomadaire des quarantaines active, pour qu'un test garé le temps d'un sprint ne reste pas garé un trimestre.
07

Update an action

action.update

Ce que tu vois dans n8n

Notes & cas d'usage

Changer un nom ou repousser une date d'expiration se fait sur place, sans recréer l'action ni perdre son identifiant.

Paramètres clés

  • Action ID : l'identifiant de l'action à modifier.
  • Name, Description et Expires After : les trois champs de mise à jour, envoyés seulement si tu les ajoutes. Toucher la date laisse donc le nom intact.
Cas d'usage
prolonger une quarantaine d'un sprint et écrire la référence du ticket dans la description au passage.

Instance

1 opération
08

Get an instance

instance.get

Ce que tu vois dans n8n

Notes & cas d'usage

Une instance correspond à l'exécution d'un fichier de spec dans un run. Cette opération la renvoie avec le détail complet des tests.

Paramètres clés

  • Instance ID : l'identifiant de l'instance d'exécution à lire.
Cas d'usage
quand une notification d'échec cite un fichier, c'est l'appel qui transforme ce nom en détail. Le message envoyé à l'équipe contient les titres des tests tombés, au lieu d'un lien que quelqu'un devra ouvrir.

Project

3 opérations
09

Get a project

project.get

Ce que tu vois dans n8n

Notes & cas d'usage

Un projet, lu par son identifiant, avec le contexte qui va autour des chiffres.

Paramètres clés

  • Project : le resource locator, choisi dans la liste ou donné par identifiant.
Cas d'usage
un générateur de rapport qui commence par lire le projet, pour que le document porte un vrai nom de projet et pas un identifiant brut. Ça compte dès que le récapitulatif sort de l'équipe technique et arrive chez quelqu'un qui n'ouvre jamais Currents.
10

Get many projects

project.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Aucun paramètre obligatoire ici, d'où son rôle de premier nœud dans beaucoup de workflows Currents.

Paramètres clés

  • Limit : le nombre maximal de projets renvoyés, pratique quand le workflow n'en cherche qu'un pour faire une correspondance.
Cas d'usage
un workflow planifié qui boucle sur tous les projets et produit un rapport d'insights par projet. Un nouveau dépôt entre ainsi dans le rapport dès sa création, sans qu'il faille s'en souvenir.
11

Get project insights

project.getInsights

Ce que tu vois dans n8n

Notes & cas d'usage

Des métriques sur une fenêtre de dates plutôt que sur un run isolé : c'est la vue qui montre une tendance.

Paramètres clés

  • Project, Date Start et Date End : les trois sont obligatoires, les dates au format ISO 8601.
  • Resolution : 1h, 1d ou 1w, la granularité de la série.
  • Branches, Tags, Groups et Git Authors : des filtres séparés par des virgules pour resserrer la fenêtre.
Cas d'usage
le point du lundi matin, en résolution 1d et sur la branche principale seulement.

Run

7 opérations
12

Cancel a run

run.cancel

Ce que tu vois dans n8n

Notes & cas d'usage

Couper un run en cours demande un seul identifiant, rien de plus.

Paramètres clés

  • Run ID : l'identifiant du run à annuler, en général trouvé par une étape précédente.
Cas d'usage
un workflow qui surveille une branche de longue durée et annule le run en cours dès qu'un revert est poussé, parce que les résultats en approche décrivent du code qui n'existe plus. Annuler explicitement produit aussi un événement propre, au lieu d'un timeout plus tard.
13

Cancel a run by GitHub CI

run.cancelGithub

Ce que tu vois dans n8n

Notes & cas d'usage

GitHub Actions a ses propres identifiants, et cette opération les accepte tels quels : aucune recherche à faire côté Currents.

Paramètres clés

  • GitHub Run ID et GitHub Run Attempt : les deux sont obligatoires, repris du run Actions et de son numéro de tentative.
  • Project ID et CI Build ID : des restrictions facultatives, quand un même run GitHub alimente plusieurs projets ou plusieurs builds.
Cas d'usage
un webhook parti d'un job Actions annulé, qui ferme le run Currents dans la foulée.
14

Delete a run

run.delete

Ce que tu vois dans n8n

Notes & cas d'usage

Suppression définitive, et les données associées au run partent avec.

Paramètres clés

  • Run ID : l'identifiant du run à supprimer.
Cas d'usage
nettoyer les runs produits par un job de CI mal configuré qui reportait sur le mauvais projet. Les laisser fausserait toutes les métriques d'instabilité ensuite. À encadrer par une étape de validation manuelle dans le workflow, puisque rien n'est réversible ici et qu'un identifiant mal repris ne se rattrape pas.
15

Find a run

run.find

Ce que tu vois dans n8n

Notes & cas d'usage

Retrouver un run quand tu n'as pas son identifiant sous la main : c'est précisément le rôle de cette opération.

Paramètres clés

  • Project : le resource locator qui cadre la recherche.
  • Branch, CI Build ID et Tags : les filtres qui désignent le run visé, par nom de branche git, par build de CI ou par tag.
Cas d'usage
une commande de chat où quelqu'un tape un nom de branche et reçoit l'état du run qui lui correspond.
16

Get a run

run.get

Ce que tu vois dans n8n

Notes & cas d'usage

Le nœud qui suit presque toujours le trigger : une fois l'identifiant en main, il renvoie le run lui-même.

Paramètres clés

  • Run ID : l'identifiant du run à lire.
Cas d'usage
la deuxième étape d'un workflow de notification, entre le trigger et le message, pour que l'alerte porte la branche et l'issue du run au lieu d'annoncer que quelque chose s'est terminé quelque part.
17

Get many runs

run.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

La seule opération qui lit un pan entier d'historique d'un coup, donc la colonne vertébrale des workflows de reporting.

Paramètres clés

  • Project : obligatoire, et Limit plafonne le nombre de runs renvoyés.
  • Status et Completion State : deux axes distincts, l'un sur PASSED ou FAILED, l'autre sur COMPLETE, CANCELED, TIMEOUT ou IN_PROGRESS.
  • Starting After et Ending Before : les curseurs repris d'une réponse précédente pour parcourir un long historique.
  • Tags avec Tag Operator : AND exige tous les tags, OR en accepte un seul.
Cas d'usage
l'export hebdomadaire des runs en échec sur la branche de release.
18

Reset a run

run.reset

Ce que tu vois dans n8n

Notes & cas d'usage

Rejouer les specs en échec sans relancer toute la suite, et sans attendre le prochain push.

Paramètres clés

  • Run ID : le run dont les specs en échec doivent repartir.
  • Machine IDs : une liste d'identifiants de machines séparés par des virgules, de 1 à 63, qui décide de la répartition du rejeu.
  • Batched Orchestration : une option qui bascule le rejeu en orchestration par lots.
Cas d'usage
une seule reprise automatique après un timeout, pour qu'un hoquet d'infrastructure ne finisse pas en build rouge relancé à la main.

Signature

1 opération
19

Generate a signature

signature.generate

Ce que tu vois dans n8n

Notes & cas d'usage

Une signature désigne un test de façon stable, d'un run à l'autre. Cette opération la fabrique.

Paramètres clés

  • Project : le resource locator auquel le test appartient.
  • Spec File Path : le chemin complet du fichier de spec.
  • Test Title : le titre du test, les blocs describe imbriqués étant reliés par le séparateur > .
Cas d'usage
le pont entre un échec et son historique, puisque la signature produite ici est ce qu'attendent Get test results et une action basée sur signature.

Spec File

1 opération
20

Get many spec files

specFile.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Des métriques agrégées par fichier de spec, sur une période, pour répondre à une question directe : quels fichiers coûtent le plus cher.

Paramètres clés

  • Project, Date Start et Date End : la fenêtre obligatoire, dates au format ISO 8601.
  • Order By avec Sort Direction : classement sur avgDuration, failureRate, flakeRate ou timeoutRate, croissant ou décroissant.
  • Include Failed in Duration : décide si les exécutions en échec comptent dans la durée.
  • Page : le numéro de page, à partir de 0.
Cas d'usage
la liste mensuelle des fichiers les plus lents à découper.

Test

1 opération
21

Get many tests

test.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

Même logique, un cran plus fin : le test plutôt que le fichier, et c'est à ce niveau que l'instabilité se voit.

Paramètres clés

  • Project, Date Start et Date End : la fenêtre obligatoire.
  • Order By : flakiness, failures, duration, plus les variantes d'impact qui pondèrent un taux par le nombre d'exécutions.
  • Minimum Executions : écarte les tests trop peu joués pour que leur taux veuille dire quelque chose.
  • Test State : ne garde que failed, passed, pending ou skipped.
Cas d'usage
le classement des tests instables qui ouvre la revue qualité.

Test Result

1 opération
22

Get test results

testResult.getAll

Ce que tu vois dans n8n

Notes & cas d'usage

L'historique d'un seul test, exécution après exécution : la vue qui tranche entre un test cassé et un test malchanceux.

Paramètres clés

  • Test Signature : obligatoire, produite par Generate a signature à partir du projet, du chemin de spec et du titre du test.
  • Date Start et Date End : la fenêtre obligatoire, au format ISO 8601.
  • Status et Branches : resserrent l'historique sur les états et les branches qui t'intéressent.
Cas d'usage
démontrer qu'un test ne tombe que sur une branche avant que quelqu'un le réécrive.
Besoin d'aide

Besoin d'aide pour automatiser Currents avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Currents et n8n, les questions qui suivent

01L'intégration Currents n8n est-elle gratuite ?
Oui du côté n8n. Le nœud Currents et le Currents Trigger sont livrés avec n8n : rien à installer, rien à payer en plus, aussi bien sur n8n Cloud que sur une instance auto-hébergée en Community Edition sous licence Sustainable Use. Un workflow construit sur l'un tourne à l'identique sur l'autre, donc rien n'empêche de prototyper sur Cloud puis de déplacer le même workflow vers une installation Docker maison. Ce que coûte un compte Currents est une autre question, qui dépend de ton offre chez eux et se vérifie directement auprès de Currents.
02Quels credentials faut-il pour connecter Currents à n8n ?
Un credential Currents, créé une seule fois dans le menu Credentials de ton instance n8n. Le nœud Currents et le Currents Trigger lisent tous les deux dans cette même entrée, donc un credential unique couvre les 22 opérations et les 4 événements du trigger. Une fois enregistré, il apparaît dans la liste déroulante de chaque nœud Currents que tu ajoutes, et le jeton ne se recopie jamais à la main dans un workflow. Le nœud ne propose pas de sélecteur d'authentification, il n'y a donc pas de méthode à choisir. Teste-le avec Get many projects, qui ne demande aucun paramètre.
03Quelles sont les limites du nœud Currents dans n8n ?
Deux points à anticiper. La pagination d'abord : les opérations de liste acceptent un Limit, Get many runs et Get test results exposent les curseurs Starting After et Ending Before qu'on reprend de la réponse précédente, tandis que Get many spec files et Get many tests se paginent avec un numéro de Page qui commence à 0. Un long historique demande donc une boucle, pas un appel unique. Ensuite, tout ce que l'API Currents propose au-delà de ces 22 opérations du catalogue passe par le nœud HTTP Request, qui atteint n'importe quel endpoint en réutilisant le même credential via l'authentification prédéfinie.
04Le Currents Trigger réagit-il en temps réel ?
Oui. Le trigger fonctionne par webhook, c'est-à-dire une URL que Currents appelle dès qu'il se passe quelque chose : l'événement arrive en quelques secondes et n8n ne va jamais interroger l'API pour savoir où en sont les runs. n8n enregistre cette URL auprès de Currents au moment de l'activation du workflow, ce qui explique qu'un workflow en brouillon ne reçoive rien. Le trigger se limite à un projet via son paramètre Project et aux événements cochés dans Events. Sans option attrape-tout, chacun des 4 événements utiles se coche explicitement.
05n8n ou Make pour Currents ?
La réponse tient à l'hébergement et au modèle de coût. Make est hébergé par Make, sans option d'auto-hébergement, et se facture à l'opération : prévisible, mais qui grimpe avec le volume. n8n tourne sur Cloud ou sur ton propre serveur via Docker ou npm, et le workflow est identique dans les deux cas, donc des données de test que tu préfères garder dans ton réseau y restent. Le nœud Currents couvre les mêmes 22 opérations de part et d'autre. Si l'automatisation se contente de lire des métriques à heure fixe, les deux font le travail. Si elle vit dans une chaîne de CI déjà auto-hébergée, garder les deux au même endroit simplifie.
Hack'celeration Lab

Reçois nos tips intégration chaque semaine.

Pas de spam. Désinscription à tout moment.

Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations