Generator pliku Jenkinsfile

Builder pliku Jenkinsfile

Narzędzie online do generowania gotowych plików Jenkinsfile dla Jenkins CI/CD. Wystarczy wypełnić formularz — narzędzie tworzy poprawny, działający skrypt pipeline w formacie Groovy DSL, gotowy do umieszczenia w repozytorium.

Jak działa generator Jenkinsfile

Generator nie analizuje repozytorium i nie łączy się z serwerem Jenkinsa. Działa w całości w przeglądarce: wartości z formularza trafiają do szablonu Groovy DSL, a wynik jest zwykłym tekstem. Nic nie jest wysyłane na żadną maszynę i nic nie jest wykonywane — wpisane komendy są wyłącznie przepisywane do pliku, a uruchomi je dopiero agent Jenkinsa po commicie do repozytorium.

Mechanizm sprowadza się do trzech kroków: odczyt pól, złożenie bloków i sformatowanie całości. Każde pole odpowiada konkretnej dyrektywie — agent, environment, options, triggers, stages, post. Puste pole nie tworzy bloku: jeśli nie podasz komendy testów, w pliku nie pojawi się żaden etap testowania, a jeśli nie zaznaczysz archiwizacji artefaktów, nie zobaczysz wywołania archiveArtifacts. Dzięki temu wynik nie zawiera pustych sekcji, które trzeba by usuwać ręcznie.

Drugi mechanizm to wybór stylu. W trybie deklaratywnym generator buduje szkielet pipeline { agent ... stages { stage { steps { sh '...' } } } } i domyka go blokiem post z sekcjami always, success i failure. W trybie skryptowym powstaje blok node { ... } z krokami opakowanymi w Groovy, a zamiast sekcji post stosuje się konstrukcję try/catch/finally. Generator pilnuje przy tym wcięć, cudzysłowów i kolejności bloków, bo w pipeline deklaratywnym kolejność sekcji nie jest dowolna, a błędne wcięcie to najczęstsza przyczyna komunikatu o nieoczekiwanym kroku.

Przykład: Jenkinsfile dla aplikacji Node.js krok po kroku

1. Wpisz nazwę projektu, na przykład sklep-api, i pozostaw styl deklaratywny, czyli Declarative Pipeline. Nazwa posłuży do opisania pipeline'u w pliku.
2. W sekcji agenta wybierz opcję Docker i podaj obraz node:alpine, żeby wszystkie kroki wykonywały się w kontenerze z Node.js, a nie na współdzielonym agencie z nieprzewidywalnym środowiskiem.
3. Uzupełnij komendy: budowanie — npm ci, testy — npm test, lintowanie — npm run lint. Każda z nich trafi do osobnego etapu i zostanie wywołana krokiem sh.
4. Zaznacz zbieranie raportów JUnit oraz archiwizację artefaktów, np. katalogu dist. Dodaj zmienną środowiskową NODE_ENV o wartości production i wpisz harmonogram cron w formacie Jenkinsa, na przykład H 2 * * 1-5.
5. Włącz opcje timestamps(), ansiColor('xterm') i disableConcurrentBuilds(), żeby log miał znaczniki czasu, kolory w konsoli, a dwa buildy tej samej gałęzi nie nakładały się na siebie.
6. Kliknij „Przetwórz”. W edytorze po prawej stronie pojawi się gotowy plik z blokiem pipeline, agentem Docker, trzema etapami i sekcją post. Skopiuj go do schowka i zapisz w katalogu głównym repozytorium pod nazwą Jenkinsfile, a następnie dodaj do kontroli wersji razem z resztą kodu.

Mapowanie pól formularza na dyrektywy Jenkinsfile

Praktyczne wskazówki

• Trzymaj jeden etap na jedną odpowiedzialność — osobny stage dla budowania, testów i lintowania daje czytelny widok w interfejsie Jenkinsa i pozwala od razu zobaczyć, który krok padł.
• Nie wpisuj sekretów wprost do pliku — tokeny rejestru Docker, klucze wdrożeniowe i hasła trzymaj w Jenkins Credentials, a w Jenkinsfile odwołuj się do nich przez credentials(). Wygenerowany plik łatwo trafia do repozytorium, więc wszystko, co w nim zapiszesz, staje się publiczne dla osób z dostępem do kodu.
• Ustawiaj opcje na poziomie całego pipeline'u — znaczniki czasu, kolory ANSI i blokada równoległych buildów dotyczą całego uruchomienia, a nie pojedynczego etapu, dlatego należą do sekcji options, a nie steps.
• Nadaj plikowi standardową nazwę i miejsce — konwencja to plik Jenkinsfile w katalogu głównym repozytorium; wtedy konfiguracja joba typu pipeline z SCM nie wymaga podawania własnej ścieżki.
• Wersjonuj zmiany jak kod produkcyjny — modyfikacje Jenkinsfile wprowadzaj przez pull request i sprawdzaj na gałęzi testowej, zanim pójdą na gałąź główną.

Czego narzędzie nie zrobi

• Nie waliduje komend — polecenia są przepisywane dosłownie. Literówka w komendzie albo brak odpowiedniego skryptu w pliku konfiguracyjnym projektu ujawni się dopiero podczas builda na agencie.
• Nie sprawdza dostępnych wtyczek — agent Docker, zbieranie raportów JUnit, kolory ANSI i kroki rejestru obrazów wymagają odpowiednich wtyczek zainstalowanych na kontrolerze Jenkinsa. Generator nie ma wglądu w konfigurację serwera.
• Nie tworzy bibliotek współdzielonych ani logiki multibranch — wygenerowany plik to pojedynczy pipeline. Dyrektywy bibliotek, własne kroki i konfiguracja skanowania gałęzi pozostają po stronie joba i repozytorium.
• Nie zna realiów Twojego środowiska — etykiety węzłów, nazwy poświadczeń, ścieżki artefaktów, strefa czasowa Jenkinsa i nazwy rejestrów to wartości, których narzędzie nie zgadnie. Po wygenerowaniu pliku trzeba je dopasować ręcznie.
• Nie generuje pliku Dockerfile ani skryptów pomocniczych — jeśli pipeline buduje obraz, sam Dockerfile i konfiguracja aplikacji muszą już istnieć w repozytorium.

Najczęstsze pytania