Bonjour à tous,
Je souhaite avoir un environnement où j’ai un A<>B. Quand A est en direct, je peux travailler sur B et ainsi de suite.
Quand je clone le workflow pour avoir une copie de la dernière version, je dois soudainement actualiser presque tous mes nœuds. Presque 100. Par exemple, les nœuds de journalisation Supabase. Mais il n’y a rien de mal, je dois juste l’ouvrir, puis il récupère la table de base de données et je peux le fermer. Mais c’est un processus lent et je dois faire cela plusieurs fois. Si je ne le fais pas, je ne peux même pas publier le workflow. J’ai l’impression que c’est un bug dans le système n8n. Peut-être que mon application est devenue trop importante pour n8n. Mais est-ce que quelqu’un connaît une solution ?
Avez-vous essayé l’import/export au lieu du clonage/duplication ?
Vous pouvez aussi copier tous les nœuds du workflow problématique puis les coller dans un nouveau workflow.
Cela vous aide-t-il ?
Merci pour votre réponse rapide !
#1 Malheureusement, la solution Git semble n’être disponible que dans le plan Business, ce qui nécessiterait une « mise à niveau » mensuelle avec des coûts considérablement plus élevés. Honnêtement, cela me semble très étrange.
#2 Un CLI n8n est-il disponible ?
#3 Mon expérience avec des workflows (sous-)divisés plus petits est en réalité que les choses deviennent moins organisées et beaucoup plus difficiles à suivre. Je dois constamment chercher :
-
quel workflow s’est arrêté ?
-
quels workflows sont connectés ?
-
lesquels dois-je ouvrir ?
Surtout avec les tests A/B. Si je passe d’1 workflow à 3 ou 4 workflows avec des variantes A/B, je pourrais facilement me retrouver avec 8 workflows et versions différents.
Pour le moment, je ne vois principalement que des inconvénients, pour être honnête. Cela dit, j’apprécie vraiment vos conseils !
@Bart_Sch
Il semble que vous devriez re-saisir (credentials),
Le nœud Code n’a pas besoin de credential, donc il n’est pas affecté…
Ce ne sont même pas des identifiants. C’est essentiellement ouvrir le nœud et le fermer. Ensuite, c’est réglé. Mais cela devrait être fait automatiquement, sans intervention, à mon avis.
Désolé, j’ai cru l’avoir mentionné, c’est une instance cloud. Mais je ne l’ai pas fait. Malheureusement, je ne peux pas l’utiliser.
Tu penses que ça va marcher alors ? Et pourquoi ?
Quoi ?! J’ai aussi des nœuds avec des identifiants différents. Donc le clonage change le flux de travail. Quel outil amateur c’est 
Oh non, et quand j’exporte et importe, le nom change en exactement le même nom de flux de travail aussi. J’ai failli casser mon flux de travail qui fonctionne…
Désolé pour tous ces messages. Mais pas de téléchargement et d’import pour moi, il y a d’autres conflits aussi parce qu’il clone exactement tout.
Bonjour @Bart_Sch, merci pour la clarification.
Je pense que le problème sous-jacent pourrait toujours être lié aux credentials, mais pas au sens d’une mauvaise valeur de credential. Puisque l’ouverture et la fermeture du nœud le font fonctionner à nouveau, cela semble plutôt indiquer que le nœud cloné ne résout pas ou ne rafraîchit pas correctement l’état des credentials jusqu’à ce que l’interface utilisateur le recharge.
Le nœud Code lui-même est probablement correct, tandis que la liaison des credentials après le clonage semble être la partie qui se bloque.
Merci encore pour les détails, cela aide beaucoup à réduire le champ des investigations.
J’ai rencontré le même problème auparavant, et la seule chose qui m’a sauvé la raison a été de resélectionner les identifiants sur un nœud, puis de dupliquer ce nœud corrigé et de copier son JSON sur les nœuds cassés. Ça reste un peu bricolé, mais ça a énormément réduit le travail fastidieux. Ça me fait penser que la fonction de clonage oublie simplement de synchroniser les états des identifiants en arrière-plan.
@Bart_Sch
Une autre solution plus sûre serait de reconstruire le workflow cloné par blocs au lieu de tenter de réparer tous les nœuds cassés à la fois. Je créerais un nouveau workflow vide, puis copierais un petit groupe de nœuds du workflow original, par exemple une section ou une intégration à la fois. Après avoir collé chaque bloc, je resélectionnerais les identifiants uniquement une fois pour ce bloc, le testerais, puis continuerais avec le bloc suivant. C’est plus lent qu’un clone complet, mais plus sûr que de modifier manuellement 100 nœuds ou de modifier le JSON exporté en masse, surtout sur Cloud. Cela aide également à identifier quel type de nœud ou quelle intégration perd son état d’identifiants après le clonage.
Je garderais le workflow original intact, construirais le remplacement sous un nom temporaire, testerais chaque section, et ne commencerais à diriger le trafic de production qu’après la validation complète de la version reconstruite.
Merci à tous pour votre aide. C’est vraiment apprécié.
Après quelques tests, j’opte finalement pour l’option Download > Import :
Je dois faire attention car le nom change selon le workflow original dont il provient. Et mon flux a un webhook qui doit être modifié et mis à jour sur 1 nœud après l’import, mais c’est bien mieux que de rouvrir tous les nœuds comme je l’ai fait au début.
Cela ressemble toujours un peu à un contournement et c’est bizarre qu’il n’y ait pas de véritable méthode Test/Prod supportée. Je pensais que ce produit était destiné à l’Entreprise. Malheureusement, l’option Git est réservée à un plan plus cher.
La deuxième option serait peut-être de construire un pipeline et de cloner et mettre à jour via API ou MCP, mais pour l’instant je n’ai pas assez de temps pour explorer cela. J’espérais une méthode intégrée.
Encore merci à tous.
Bart
