Pourquoi le rapport de migration n’a-t-il pas été généré lors de la mise à niveau de 1.109.2 à 2.32.7 ?
Comment pouvons-nous vérifier la compatibilité des flux de travail avec la nouvelle version sans le rapport de migration ?
Y a-t-il des modifications non rétrocompatibles entre 1.109.2 et 2.32.7 dont nous devrions être conscients ?
Hé @hemchandra, en attendant une réponse, voici quelques ressources qui pourraient vous aider :
Ressources suggérées
Automatiquement associées à votre question.
Documentation :
Forum :
@mohamed3nan, @A_A4, @Lam_Minh_Phan - vous avez aidé sur des problèmes similaires auparavant, pouvez-vous y jeter un œil ?
Suggéré automatiquement par le bot communautaire de n8n. C’est un projet pilote - veuillez partager vos commentaires ici.
Salut @hemchandra Bienvenue !
Il a été livré dans 1.121.0, donc 1.109.2 ne l’a jamais eu. C’est aussi un outil de pré-mise à niveau qui analyse une instance 1.x, et non quelque chose que la mise à niveau produit :
Vous êtes déjà sur 2.32.7, donc les exécutions échouées depuis la mise à niveau montrent ce qui s’est réellement cassé. Pour obtenir le rapport formel, pointez une instance scratch 1.121.x vers une copie de votre base de données pré-mise à niveau et ouvrez Paramètres > Rapport de migration.
Oui, tout l’ensemble v2.0. Celle qui ne lance aucune erreur est les données de retour des sous-workflows : un parent reçoit maintenant la sortie de l’enfant au lieu de sa propre entrée.
quelles sont les façons dont nous pouvons faire ce test de compatibilité
Deux façons, statique puis dynamique.
Exportez tous les workflows dans un fichier et cherchez-y ce qui a changé en v2:
n8n export:workflow --all --output=workflows.json
grep -nE 'nodes-base.start|evaluateExpression|executeCommand|localFileTrigger|readWriteFile|waitForSubWorkflow' workflows.json
Chaque résultat est un workflow à ouvrir par rapport à la liste des changements incompatibles. Sur Docker, préfixez avec docker exec -u node -it <container-name>.
Puis exécutez ceux qui importent sans attendre un déclencheur:
n8n execute --id <ID>
Merci pour votre réponse.
Pouviez-vous préciser l’environnement d’exécution de ces commandes ? Nous exécutons n8n sur OpenShift (Kubernetes). Quelle serait l’approche équivalente pour notre configuration ?
Mêmes commandes, oc exec à la place de docker exec. Il n’y a pas d’équivalent -u node, oc exec ne peut pas sélectionner un utilisateur, et sous le SCC restreint, le pod s’exécute déjà en tant qu’UID arbitraire dans le groupe 0.
Cet UID ne peut pas non plus écrire n’importe où dans le conteneur, donc supprimez --output et laissez l’export s’afficher sur stdout, redirigé sur votre propre machine :
oc exec deploy/n8n -- n8n export:workflow --all > workflows.json
Pas de -it là-dessus, un TTY corrompt la redirection. Filtrez ce fichier localement. L’exécution elle-même reste à l’intérieur du pod :
oc exec -it deploy/n8n -- n8n execute --id <ID>