Jenkins na sterydach: Jak n8n i Langfuse zmieniają monitorowanie CI/CD

Koniec ze "ścianą tekstu" w konsoli

Każdy inżynier DevOps i programista zna ten ból. Pipeline w Jenkinsie świeci się na czerwono. Klikasz w szczegóły builda, otwierasz konsolę i dostajesz w twarz tysiącami linii surowego tekstu. Gdzieś tam, między inicjalizacją zmiennych środowiskowych a pobieraniem zależności, ukryty jest błąd. Grepujesz, scrollujesz, mrużysz oczy. To archaiczne podejście.

W świecie mikroserwisów i złożonych systemów rozproszonych nauczyliśmy się używać tracingu (np. Jaeger czy Zipkin). Dlaczego więc nasze procesy CI/CD wciąż traktujemy jak czarne skrzynki wypluwające tekst? Czas to zmienić, łącząc trzy narzędzia, które na pozór są z innych bajek: Jenkinsa (klasyka), n8n (automatyzacja low-code) i Langfuse (observability dla LLM).

Dlaczego Langfuse do CI/CD?

To może brzmieć kontrowersyjnie. Langfuse jest pozycjonowany jako narzędzie do monitorowania aplikacji opartych na dużych modelach językowych (LLM). Jednak jeśli spojrzysz na to, jak Langfuse strukturyzuje dane, zobaczysz coś więcej: doskonały silnik do wizualizacji zagnieżdżonych procesów.

Pipeline Jenkinsa to w istocie seria kroków (spans), które mają swoje wejścia, wyjścia, czas trwania i status końcowy. Langfuse pozwala wizualizować te kroki jako drzewo wywołań (trace). Zamiast czytać logi linearnie, widzisz dokładnie, który etap trwał za długo, jakie parametry weszły do funkcji testującej i co dokładnie zwrócił skrypt deployujący. To, co Langfuse nazywa "trace", dla nas staje się "pojedynczym uruchomieniem builda".

Rola n8n: Klej, który trzyma to razem

Jenkins sam z siebie nie wyśle ładnych danych do Langfuse. Mógłbyś pisać skomplikowane skrypty w Groovy lub Pythonie wewnątrz pipeline'u, ale to proszenie się o kłopoty przy utrzymaniu. Tutaj wchodzi n8n.

n8n działa jako warstwa pośrednia (middleware). Jego zadanie jest proste:

1. Odbiór: Słucha webhooków wysyłanych przez Jenkinsa na różnych etapach pipeline'u (Start, Stage Finish, End).
2. Transformacja: Parsuje JSON z Jenkinsa, wyciąga kluczowe informacje (nazwa builda, status, logi błędów).
3. Wysyłka: Komunikuje się z API Langfuse, tworząc odpowiednie obiekty typu Trace, Span lub Event.

Dzięki temu logika monitorowania jest wyciągnięta poza kod aplikacji i poza konfigurację samego Jenkinsa. Chcesz zmienić sposób raportowania błędów? Edytujesz workflow w n8n, nie dotykając Jenkinsfile.

Architektura rozwiązania

1. Konfiguracja Jenkinsa

Wymagane jest zainstalowanie wtyczki Notification Plugin lub użycie natywnej funkcji httpRequest w Groovy. Najczystszym rozwiązaniem jest zdefiniowanie globalnego listenera lub bloku post w pipeline deklaratywnym:

post {
    always {
        httpRequest url: 'https://twoje-n8n.com/webhook/jenkins-event', 
        httpMode: 'POST', 
        requestBody: groovy.json.JsonOutput.toJson([
            buildId: env.BUILD_ID,
            stage: 'Final',
            status: currentBuild.currentResult
        ])
    }
}

2. Workflow w n8n

W n8n tworzymy webhook, który odbiera dane. Następnie musimy obsłużyć logikę stanu. Langfuse wymaga ID śladu (Trace ID). Najlepiej użyć numeru builda Jenkinsa jako unikalnego identyfikatora śladu w Langfuse. Dzięki temu, gdy Jenkins wyśle informację o zakończeniu etapu "Unit Tests", n8n wie, do którego śladu w Langfuse "dolepić" ten span.

Workflow powinien obsługiwać:

• Inicjalizację (Trace Creation): Gdy build startuje, n8n tworzy nowy Trace w Langfuse.
• Aktualizację (Span Generation): Każdy stage w Jenkinsie to osobny span w Langfuse. Jeśli etap zawierał wywołanie AI (np. automatyczne code review), możemy to zagnieździć jeszcze głębiej.
• Finalizację (Scoring): Status builda (SUCCESS/FAILURE) mapujemy na "Score" w Langfuse. To pozwala później filtrować dane i np. wyciągnąć statystyki: "pokaż mi wszystkie buildy, które padły na etapie E2E tests".

Debugowanie błędów w praktyce

Wyobraź sobie, że build padł. Zamiast wchodzić do Jenkinsa, wchodzisz do Langfuse. Widzisz listę ostatnich uruchomień. Klikasz w czerwony Trace.

Widzisz wizualną reprezentację czasu. Od razu rzuca się w oczy, że etap "Docker Build" trwał 4 minuty zamiast standardowych 30 sekund. Klikasz w ten span. W sekcji "Output" n8n wstrzyknął ostatnie 50 linii logów z Jenkinsa dotyczących tylko tego etapu. Widzisz błąd timeoutu przy pobieraniu paczki z npm.

Masz kontekst, masz czas trwania i masz wyizolowany błąd – wszystko w jednym, czytelnym dashboardzie. Co więcej, możesz dodać tagi do śladu, np. branch:feature/login lub author:jan.kowalski, co pozwala na błyskawiczne znalezienie, kto zepsuł builda i kiedy.

Gdy w grę wchodzi AI

Integracja ta zyskuje podwójne znaczenie, jeśli Twoje pipeline'y faktycznie używają LLM-ów. Coraz częściej wdrażamy kroki takie jak:

• Automatyczna generacja changeloga przez GPT-4.
• Analiza bezpieczeństwa kodu przez dedykowanego agenta.
• Tłumaczenie plików i18n w locie.

W takim scenariuszu Langfuse jest w swoim naturalnym środowisku. Możesz monitorować nie tylko techniczny sukces builda Jenkinsa, ale też jakość odpowiedzi modelu, koszt tokenów zużytych podczas CI/CD oraz ewentualne halucynacje w generowanej dokumentacji. n8n przesyła wtedy nie tylko metadane Jenkinsa, ale też pełny prompt i odpowiedź modelu, tworząc kompletny obraz procesu wytwórczego.