Wczoraj testowałem FlowLint CLI i jedna rzecz natychmiast przyszła mi do głowy: 👉 To narzędzie czyni moje workflow n8n solidnymi.
Już dodałem je do mojego publicznego repozytorium n8n-workflows wraz z plikiem konfiguracyjnym YAML .flowlint --- i tak po prostu zaczęło działać bezproblemowo!
Szybka konfiguracja
Aby zacząć używać FlowLint CLI, wykonaj poniższe kroki.
1. NPM Init w katalogu workflow n8n
Uruchom npm init, aby rozpocząć projekt node w katalogu, gdzie przechowujesz swoje workflow n8n:
npm init
2. Ustaw komendę test
Podczas konfiguracji, gdy zostaniesz zapytany o komendę test, wpisz:
flowlint scan
3. Zainstaluj FlowLint
Następnie zainstaluj FlowLint:
npm i flowlint
I... jesteś gotowy!
Przetestuj Flowlint z CLI
Teraz po prostu uruchom:
npm run test
FlowLint automatycznie zlintuje wszystkie workflow zdefiniowane w twoim katalogu. Jeśli chcesz określić, które pliki lintować, możesz użyć konfiguracji YAML.
Konfiguracja YAML Flowlint
Aby dostosować własną konfigurację FlowLint, możesz użyć pliku konfiguracyjnego YAML przechowywanego w głównym katalogu projektu w pliku .flowlint.yml. Poniżej znajduje się przykładowy plik konfiguracyjny z mojego repozytorium n8n-workflows:
version: 1
files:
include:
- "**/*.n8n.json"
- "**/workflows/**/*.json"
ignore:
- "samples/**"
- "creators-portal/**"
- "**/*.spec.json"
- "guardrails-pass-an-object.json"
- "guardrails-testing.json"
report:
annotations: true
summary_limit: 25
rules:
rate_limit_retry:
enabled: true
max_concurrency: 5
error_handling:
enabled: true
forbid_continue_on_fail: true
secrets:
enabled: true
idempotency:
enabled: true
dead_ends:
enabled: true
long_running:
enabled: true
max_iterations: 1000
timeout_ms: 300000
Sekcja files w .flowlint.yml
Ważna część z sekcji files to:
files:
include:
- "**/*.n8n.json"
- "**/workflows/**/*.json"
ignore:
- "samples/**"
- "creators-portal/**"
- "**/*.spec.json"
- "guardrails-pass-an-object.json"
- "guardrails-testing.json"
Ten plik konfiguracyjny sprawdza wszystkie workflow w moim repozytorium, z wyjątkiem tych w katalogu samples, katalogu creators-portal, plików **/*.spec.json, guardrails-pass-an-object.json i guardrails-testing.json.
Mówiąc prosto, możesz wskazać, które pliki FlowLint powinien sprawdzać, a które ignorować.
Sekcja rules w .flowlint.yml
Spójrzmy na sekcję rules:
rules:
rate_limit_retry:
enabled: true
max_concurrency: 5
error_handling:
enabled: true
forbid_continue_on_fail: true
secrets:
enabled: true
idempotency:
enabled: true
dead_ends:
enabled: true
long_running:
enabled: true
max_iterations: 1000
timeout_ms: 300000
Jeśli chcesz wyłączyć regułę, możesz ustawić rate_limit_retry: false.
Np. jeśli chcesz wyłączyć regułę rate_limit_retry, możesz ustawić rate_limit_retry: enabled: false.
Z tą opcją wyłączoną, FlowLint nie będzie sprawdzać retry przy limitach szybkości w twoich workflow.
Ale jeśli chcesz ją włączyć, możesz ustawić
rate_limit_retry:
enabled: true
i w konsoli zobaczysz coś takiego:
MUST R1 Node HTTP Request is missing retry/backoff configuration
at flowlint/001-basic-state.n8n.json:75
In the node properties, enable "Retry on Fail" under Options.
Czy już to testowałeś?
Kilka dni temu napisałem post o FlowLint na LinkedIn - linterze n8n dostępnym jako aplikacja GitHub. Wczoraj Martin Holý (dzięki, Martin! 🙌) poinformował mnie o nowym FlowLint CLI i to game-changer.
Jeśli jesteś fanem #n8n, musisz to sprawdzić. To narzędzie pomoże ci uczynić twoje workflow bardziej niezawodnymi, łatwiejszymi w utrzymaniu i odpornymi na błędy.
Więcej informacji o FlowLint CLI: https://flowlint.dev/
Repozytorium n8n-workflows, gdzie możesz znaleźć przykładowe workflow i gotową do użycia konfigurację FlowLint: https://github.com/pjsikora/n8n-workflows
