Podczas pisania potoków Jenkins wydaje się bardzo niewygodne zatwierdzanie każdej nowej zmiany, aby sprawdzić, czy działa.

Czy istnieje sposób, aby wykonać je lokalnie bez zatwierdzania kodu?

Nie można wykonać skryptu Pipeline lokalnie, ponieważ jego jedynym celem jest wykonanie skryptu Jenkins. (Co jest jednym z powodów, dla których najlepiej jest trzymać się Jenkinsfilekrótkiego i ograniczonego do kodu, który faktycznie zajmuje się funkcjami Jenkinsa; twoja logika kompilacji powinna być obsługiwana za pomocą zewnętrznych procesów lub narzędzi budowania, które wywołujesz za pomocą jednego wiersza shlub batkroku.)

Jeśli chcesz przetestować zmiany na Jenkinsfileżywo, ale bez popełniania go użyć do powtórki funkcji dodanej w 1.14

JENKINS-33925 śledzi pożądane zautomatyzowane środowisko testowe.

Mam rozwiązanie, które działa dobrze dla mnie. Składa się z lokalnego jenkinsa uruchomionego w oknie dokowanym i haka sieciowego git, który uruchamia potok w lokalnych jenkinsach przy każdym zatwierdzeniu. Nie musisz już naciskać na repozytorium github lub bitbucket, aby przetestować potok.

Zostało to przetestowane tylko w środowisku Linux.

Wykonanie tej czynności jest dość proste, chociaż ta instrukcja jest trochę długa. Większość kroków już tam jest.

Właśnie tego potrzebujesz

• Docker zainstalowany i działa. To nie jest część tej instrukcji.
• Jenkins uruchomiony lokalnie w oknie dokowanym. Wyjaśniono, jak poniżej.
  • Odpowiednie prawa (klucz dostępu ssh) dla lokalnego użytkownika dokera Jenkins do pobrania z lokalnego repozytorium git. Wyjaśniono, jak poniżej.
  • Projekt potoku Jenkins, który pobiera z lokalnego repozytorium git. Wyjaśniono poniżej.
  • Użytkownik git w lokalnej Jenkins z minimalnymi uprawnieniami. Wyjaśniono poniżej.
• Projekt git z hakiem sieciowym po zatwierdzeniu, który uruchamia projekt potoku. Wyjaśniono poniżej.

Tak to się robi

Jenkins Docker

Utwórz plik o nazwie Dockerfile w miejscu swojego wyboru. Wstawiam to, /opt/docker/jenkins/Dockerfilewypełnij to:

FROM jenkins/jenkins:lts
USER root
RUN apt-get -y update && apt-get -y upgrade
# Your needed installations goes here
USER jenkins

Zbuduj obraz local_jenkins

Musisz to zrobić tylko raz lub po dodaniu czegoś do Dockerfile.

$ docker build -t local_jenkins /opt/docker/jenkins/

Uruchom i uruchom ponownie local_jenkins

Od czasu do czasu chcesz łatwo uruchamiać i ponownie uruchamiać jenkins. Np. Po ponownym uruchomieniu komputera. W tym celu utworzyłem alias, który umieszczam w .bash_aliasesfolderze domowym.

$ echo "alias localjenkinsrestart='docker stop jenkins;docker rm jenkins;docker run --name jenkins -i -d -p 8787:8080 -p 50000:50000 -v /opt/docker/jenkins/jenkins_home:/var/jenkins_home:rw local_jenkins'" >> ~/.bash_aliases
$ source .bash_aliases  # To make it work

Upewnij się, że /opt/docker/jenkins/jenkins_homefolder istnieje i że masz prawa do odczytu i zapisu do niego.

Aby uruchomić lub ponownie uruchomić jenkins, po prostu wpisz:

$ localjenkinsrestart

Wszystko, co robisz w swoich lokalnych jenkinsach, będzie przechowywane w folderze / opt / docker / jenkins / jenkins_home i zachowane między restartami.

Utwórz klucz dostępu ssh w jenkins dokera

Jest to bardzo ważna część, aby to zadziałało. Najpierw uruchamiamy kontener dokera i tworzymy dla niego powłokę bash:

$ localjenkinsrestart
$ docker exec -it jenkins /bin/bash

Wszedłeś już do kontenera dokowanego, co możesz zobaczyć na przykład jenkins@e7b23bad10aa:/$w swoim terminalu. Hash po @ na pewno się różni.

Utwórz klucz

jenkins@e7b23bad10aa:/$ ssh-keygen

Naciśnij Enter na wszystkie pytania, dopóki nie pojawi się monit

Skopiuj klucz na swój komputer. Z wewnątrz kontenera dokowanego twój komputer to 172.17.0.1.

jenkins@e7b23bad10aa:/$ ssh-copy-id [email protected]

użytkownik = twoja nazwa użytkownika i 172.17.0.1 to adres IP twojego komputera z kontenera dokera.

W tym momencie będziesz musiał wpisać swoje hasło.

Teraz spróbujmy zakończyć pętlę, wysyłając ssh-s do komputera z poziomu kontenera dokowanego.

jenkins@e7b23bad10aa:/$ ssh [email protected]

Tym razem nie musisz wprowadzać hasła. Jeśli to zrobisz, coś poszło nie tak i musisz spróbować ponownie.

Będziesz teraz w folderze domowym komputera. Spróbuj lsi spójrz.

Nie zatrzymuj się tutaj, ponieważ mamy łańcuch muszli ssh, z których musimy się wydostać.

$ exit
jenkins@e7b23bad10aa:/$ exit

Dobrze! Teraz wróciliśmy i jesteśmy gotowi, aby kontynuować.

Zainstaluj swoje Jenkins

Znajdziesz lokalnego Jenkinsa w przeglądarce pod adresem http: // localhost: 8787 .

Za pierwszym razem, gdy wskażesz przeglądarkę lokalnemu Jenkinsowi, zostaniesz przywitany za pomocą Kreatora instalacji. Domyślne ustawienia są w porządku, upewnij się jednak, że instalujesz wtyczkę potoku podczas instalacji.

Skonfiguruj swoje jenkins

Jest bardzo ważne , aby aktywować matrycy bezpieczeństwa opartej na http: // localhost: 8787 / configureSecurity i dać sobie wszelkie prawa , dodając się do matrycy i wszystko pasowało. (Po prawej stronie znajduje się ikona zaznaczania wszystkich pól)

• Wybierz Jenkins’ own user databasejako królestwo bezpieczeństwa
• Wybierz Matrix-based securityw sekcji Autoryzacja
• Wpisz swoją nazwę użytkownika w polu User/group to add:i kliknij [ Add ]przycisk
• W powyższej tabeli twoja nazwa użytkownika powinna pojawić się obok ikony osoby. Jeśli jest przekreślony, wpisałeś niepoprawnie swoją nazwę użytkownika.
• Przejdź do skrajnej prawej części tabeli i kliknij przycisk zaznacz wszystko lub ręcznie zaznacz wszystkie pola w rzędzie.
• Sprawdź, czy pole wyboru Prevent Cross Site Request Forgery exploitsnie jest zaznaczone. (Ponieważ ten Jenkins jest dostępny tylko z twojego komputera, nie jest to taka wielka sprawa)
• Kliknij [ Save ]i wyloguj się z Jenkins, a następnie ponownie, aby upewnić się, że działa. Jeśli tak nie jest, musisz zacząć od początku i opróżnić /opt/docker/jenkins/jenkins_homefolder przed ponownym uruchomieniem

Dodaj użytkownika git

Musimy zezwolić naszemu haczykowi na logowanie się do naszego lokalnego Jenkinsa z minimalnymi uprawnieniami. Wystarczy zobaczyć i zbudować miejsca pracy. Dlatego tworzymy użytkownika o nazwie gitz hasłem login.

Skieruj swoją przeglądarkę na http: // localhost: 8787 / securityRealm / addUser i dodaj gitjako nazwę użytkownika i loginhasło. Kliknij na [ Create User ].

Dodaj prawa do użytkownika git

Przejdź do strony http: // localhost: 8787 / configureSecurity w przeglądarce. Dodaj użytkownika git do macierzy:

• Napisz gitw polu User/group to add:i kliknij[ Add ]

Teraz nadszedł czas, aby zaznaczyć pola minimalnych praw użytkownika git. Potrzebne są tylko te:

• ogólnie: przeczytaj
• praca: budować
• praca: odkryj
• praca: czytaj

Upewnij się, że pole Prevent Cross Site Request Forgery exploitswyboru nie jest zaznaczone i kliknij[ Save ]

Utwórz projekt rurociągu

Zakładamy, że mamy nazwę użytkownika useri nasz projekt z włączoną obsługą git z Jenkinsfilenią się nazywa projecti znajduje się pod adresem/home/user/projects/project

W swoim http: // localhost: 8787 Jenkins dodaj nowy projekt potoku. Nazwałem to hookpipeline w celach informacyjnych.

• Kliknij New Itemw menu Jenkins
• Nazwij projekt hookpipeline
• Kliknij Rurociąg
• Kliknij [ OK ]
• Zaznacz pole wyboru Poll SCMw sekcji Wyzwalacze kompilacji. Pozostaw harmonogram pusty.
• W sekcji Rurociąg:
  • Wybierz Pipeline script from SCM
  • w Repository URLpolu wpisz[email protected]:projects/project/.git
  • w Script Pathpolu wpiszJenkinsfile
• Zapisz projekt hookpipeline
• Zbuduj hookpipeline raz, jest to potrzebne do rozpoczęcia działania Ankiety SCM.

Utwórz git hook

Przejdź do /home/user/projects/project/.git/hooksfolderu i utwórz plik o nazwie, post-commitktóry zawiera:

#!/bin/sh
BRANCHNAME=$(git rev-parse --abbrev-ref HEAD)
MASTERBRANCH='master'

curl -XPOST -u git:login http://localhost:8787/job/hookpipeline/build
echo "Build triggered successfully on branch: $BRANCHNAME"

Udostępnij ten plik jako wykonywalny:

$ chmod +x /home/user/projects/project/.git/hooks/post-commit

Przetestuj hak po zatwierdzeniu:

$ /home/user/projects/project/.git/hooks/post-commit

Sprawdź w Jenkins, czy Twój projekt hookpipeline został uruchomiony.

Na koniec dokonaj dowolnych zmian w projekcie, dodaj zmiany i dokonaj zatwierdzenia. Spowoduje to teraz uruchomienie potoku w lokalnym Jenkins.

Szczęśliwe dni!

TL; DR

• Struktura testowa Jenkins Pipeline Unit
• Jenkinsfile Runner

Długa wersja
Testy rurociągów Jenkins stają się coraz bardziej uciążliwe. W przeciwieństwie do klasycznej metody deklaratywnej konfiguracji zadania, w której użytkownik był ograniczony do tego, co ujawnił interfejs użytkownika, nowy Jenkins Pipeline jest pełnoprawnym językiem programowania dla procesu kompilacji, w którym część deklaratywną miesza się z własnym kodem. Jako dobrzy programiści chcemy również przeprowadzić testy jednostkowe dla tego rodzaju kodu.

Przy opracowywaniu rurociągów Jenkins należy wykonać trzy kroki. Etap 1. powinno obejmować 80% przypadków zastosowań.

1. Rób jak najwięcej w skryptach kompilacji (np. Maven, Gradle, Gulp itp.). Następnie w skryptach potoku wywołuje zadania kompilacji we właściwej kolejności. Potok kompilacji po prostu koordynuje i wykonuje zadania kompilacji, ale nie ma żadnej logiki, która wymagałaby specjalnego testowania.
2. Jeśli poprzedniej reguły nie można w pełni zastosować, przejdź do bibliotek współdzielonych rurociągu, gdzie możesz samodzielnie opracować i przetestować niestandardową logikę i zintegrować ją z potokiem.
3. Jeśli wszystkie powyższe problemy Cię zawiodą, możesz wypróbować jedną z bibliotek, które pojawiły się niedawno (marzec 2017 r.). Struktura testowa Jenkins Pipeline Unit lub pipelineUnit (przykłady). Od 2018 roku dostępny jest także Jenkinsfile Runner , pakiet do wykonywania potoków Jenkins z narzędzia wiersza poleceń.

Przykłady

PipelineUnit GitHub repo zawiera kilka przykładów Spocka na temat korzystania Jenkins Pipeline Jednostka testowania ramy

Jenkins ma funkcję „Powtórz”, która umożliwia szybkie odtworzenie zadania bez aktualizacji źródeł:

W momencie pisania (pod koniec lipca 2017 r.) Za pomocą wtyczki Blue Ocean możesz sprawdzić składnię deklaratywnego potoku bezpośrednio w edytorze wizualnych potoków . Edytor działa z interfejsu Blue Ocean, kiedy klikniesz „konfiguruj” tylko dla projektów github (jest to znany problem i pracują nad tym, aby działał również na git itp.).

Ale, jak wyjaśniono w tym pytaniu , możesz otworzyć przeglądarkę edytora, aby:

[Jenkins URL]/blue/organizations/jenkins/pipeline-editor/

Następnie kliknij na środku strony i naciśnij Ctrl+S, otworzy się obszar tekstowy, w którym możesz wkleić deklaratywny skrypt potoku. Jeśli klikniesz Aktualizuj , jeśli wystąpi błąd składniowy, edytor poinformuje Cię, gdzie jest błąd składniowy. Jak na tym zrzucie ekranu:

Jeśli nie wystąpi błąd składni, obszar tekstowy zostanie zamknięty, a strona wizualizuje Twój potok. Nie martw się, nic nie uratuje (jeśli jest to projekt github, zatwierdziłby zmianę Jenkinsfile).

Jestem nowy w Jenkins i to jest całkiem pomocne, bez tego musiałem wielokrotnie popełniać plik Jenkins, aż zadziała (bardzo denerwujące!). Mam nadzieję że to pomoże. Twoje zdrowie.

Trochę za późno na imprezę, ale dlatego napisałem jenny, małą reimplementację niektórych podstawowych kroków Jenkinsfile. ( https://github.com/bmustiata/jenny )

O ile mi wiadomo ta wtyczka do potoku jest „silnikiem” nowej mechaniki Jenkinsfile, więc jestem całkiem pewny, że możesz użyć tego do lokalnego testowania swoich skryptów.

Nie jestem pewien, czy potrzebne są dodatkowe kroki podczas kopiowania do pliku Jenkins, jednak składnia itp. Powinna być dokładnie taka sama.

Edycja: Znaleziono odniesienie do „silnika”, sprawdź ten opis funkcji, ostatni akapit, pierwszy wpis.

W mojej konfiguracji programistycznej - brak odpowiedniego edytora Groovy - wiele problemów z Jenkinsfile wynika z prostych błędów składniowych . Aby rozwiązać ten problem, możesz sprawdzić poprawność pliku Jenkins względem instancji Jenkins (działającej w $JENKINS_HTTP_URL):

curl -X POST -H $(curl '$JENKINS_HTTP_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,":",//crumb)') -F "jenkinsfile=<Jenkinsfile" $JENKINS_HTTP_URL/pipeline-model-converter/validate

Powyższe polecenie jest nieznacznie zmodyfikowaną wersją https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Validating-(or-linting)-a-Declarative-Jenkinsfile-from-the-command-line

Oprócz funkcji powtórki, o której wspominali już inni (to samo dotyczy jej przydatności!), Znalazłem również następujące informacje:

1. Utwórz testowe zadanie Pipeline, w którym możesz wpisać kod Pipeline lub wskazać repo / oddział pliku Jenkins, aby szybko coś przetestować. Aby uzyskać dokładniejsze testy, użyj rurociągu Multibranch, który wskazuje na własny widelec, w którym możesz szybko wprowadzać zmiany i zatwierdzać bez wpływu na prod. Rzeczy takie jak BRANCH_NAME env są dostępne tylko w Multibranch.
2. Ponieważ Jenkinsfile jest kodem Groovy, po prostu wywołaj go za pomocą „groovy Jenkinsfile”, aby zweryfikować podstawową składnię.

Umieść swój klucz SSH w swoim profilu Jenkins, a następnie użyj deklaratywnej wkładki w następujący sposób:

ssh jenkins.hostname.here declarative-linter < Jenkinsfile

Spowoduje to wykonanie analizy statycznej pliku Jenkinsfile. W wybranym edytorze zdefiniuj skrót klawiaturowy, który uruchamia to polecenie automatycznie. W Visual Studio Code, którego używam, przejdź do Zadania> Konfiguruj zadania, a następnie użyj następującego JSON, aby utworzyć polecenie Sprawdź poprawność Jenkinsfile :

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Validate Jenkinsfile",
      "type": "shell",
      "command": "ssh jenkins.hostname declarative-linter < ${file}"
    }
  ]
}

używam powtórki w przyszłości, aby dokonać aktualizacji i uruchomić szybko.

Z pewnymi ograniczeniami i dla skryptowanych potoków używam tego rozwiązania:

1. Rurociąg z wbudowanym skryptem Groovy:

node('master') {
    stage('Run!') {
                def script = load('...you job file...')
    }
}

2. Plik Jenkinsfile do testowania ma taką samą strukturę jak dla lesfurets:

def execute() {
 ... main job code here ...
}
execute()