Warum wurde der Migrationsbericht beim Upgrade von 1.109.2 auf 2.32.7 nicht generiert?
Wie können wir die Workflow-Kompatibilität mit der neuen Version ohne den Migrationsbericht überprüfen?
Gibt es Breaking Changes zwischen 1.109.2 und 2.32.7, die wir beachten sollten?
Hey @hemchandra, während du auf eine Antwort wartest, sind hier ein paar Dinge, die dir helfen könnten:
Empfohlene Ressourcen
Automatisch auf deine Frage abgestimmt.
Dokumentation:
Forum:
@mohamed3nan, @A_A4, @Lam_Minh_Phan - ihr habt bei ähnlichen Problemen schon geholfen, könnt ihr einen Blick darauf werfen?
Automatisch vorgeschlagen durch n8n’s Community Bot. Dies ist ein Pilotprojekt – bitte teilt hier euer Feedback mit.
Hi @hemchandra Willkommen!
Es wurde in 1.121.0 ausgeliefert, daher hatte 1.109.2 es nie. Es ist auch ein Pre-Upgrade-Tool, das eine 1.x-Instanz scannt, nicht etwas, das das Upgrade produziert:
Sie sind bereits auf 2.32.7, daher zeigen die fehlgeschlagenen Ausführungen seit dem Upgrade, was tatsächlich kaputt gegangen ist. Um den formalen Bericht zu erhalten, verweisen Sie eine Scratch-Instanz 1.121.x auf eine Kopie Ihrer Vor-Upgrade-Datenbank und öffnen Sie Einstellungen > Migrationsbericht.
Ja, die gesamte v2.0-Serie. Der, der keinen Fehler auslöst, sind Sub-Workflow-Rückgabedaten – ein Parent erhält jetzt die Ausgabe des Child statt seiner eigenen Eingabe.
Welche Möglichkeiten haben wir, um diesen Kompatibilitätstest durchzuführen?
Zwei Wege, statisch dann dynamisch.
Exportiere jeden Workflow in eine Datei und durchsuche sie nach dem, was sich in v2 geändert hat:
n8n export:workflow --all --output=workflows.json
grep -nE 'nodes-base.start|evaluateExpression|executeCommand|localFileTrigger|readWriteFile|waitForSubWorkflow' workflows.json
Jedes Ergebnis ist ein Workflow, den du gegen die Liste der Breaking Changes überprüfen musst. Bei Docker mit docker exec -u node -it <container-name> voranstellen.
Führe dann die relevanten Workflows aus, ohne auf einen Trigger zu warten:
n8n execute --id <ID>
Danke für die Antwort.
Könnten Sie bitte die Ausführungsumgebung für diese Befehle klären? Wir führen n8n auf OpenShift (Kubernetes) aus. Welcher äquivalente Ansatz würde für unser Setup gelten?
Gleiche Befehle, oc exec anstelle von docker exec. Es gibt kein -u node Äquivalent, oc exec kann keinen Benutzer auswählen, und unter dem restricted SCC läuft der Pod bereits als beliebige UID in Gruppe 0.
Diese UID kann auch nicht überall im Container schreiben, daher --output weglassen und den Export auf stdout streamen, auf deinem eigenen Rechner umgeleitet:
oc exec deploy/n8n -- n8n export:workflow --all > workflows.json
Kein -it dabei, ein TTY beschädigt die Umleitung. Grep auf die Datei lokal anwenden. Die Ausführung selbst bleibt im Pod:
oc exec -it deploy/n8n -- n8n execute --id <ID>