Potok skryptowy Jenkinsa lub potok deklaratywny


100

Próbuję przekonwertować mój przepływ pracy w starym stylu projektu na potok oparty na Jenkins. Przeglądając dokumenty, odkryłem, że istnieją dwie różne składnie o nazwach scriptedi declarative. Na przykład declarativeniedawno wydana składnia internetowa Jenkins (koniec 2016 r.). Chociaż pojawiło się nowe wydanie składni, Jenkins nadal obsługuje również składnię skryptową.

Teraz nie jestem pewien, w której sytuacji każdy z tych dwóch typów byłby najlepiej dopasowany. A więc będzie declarativeprzyszłość rurociągu Jenkins?

Każdy, kto może podzielić się przemyśleniami na temat tych dwóch typów składni.


2
Nie widzę niczego, aby skrypt skryptowy stał się przestarzały, a to byłoby niepokojące, biorąc pod uwagę lukę między funkcjami deklaratywnymi i skryptowymi.
Matt Schuchard

@MattSchuchard nadal wydaje się mieć rację, 3 lata później. Zrobiłem krok, aby edytować to teraz poza dyskusją.
cellepo

Odpowiedzi:


89

Kiedy powstał Jenkins Pipeline, jako fundament wybrano Groovy. Jenkins od dawna jest dostarczany z wbudowanym silnikiem Groovy, aby zapewnić zaawansowane możliwości tworzenia skryptów zarówno dla administratorów, jak i użytkowników. Dodatkowo, twórcy Jenkins Pipeline odkryli, że Groovy jest solidnym fundamentem, na którym można zbudować to, co obecnie nazywa się DSL „Scripted Pipeline”.

Ponieważ jest to w pełni funkcjonalne środowisko programistyczne, Scripted Pipeline oferuje użytkownikom Jenkins ogromną elastyczność i możliwość rozbudowy. Krzywa uczenia się Groovy'ego nie jest zwykle pożądana dla wszystkich członków danego zespołu, więc Declarative Pipeline został stworzony, aby zaoferować prostszą i bardziej upartą składnię do tworzenia Jenkins Pipeline.

Oba są zasadniczo tym samym podsystemem rurociągów poniżej. Oba są trwałymi implementacjami „potoku jako kodu”. Oboje są w stanie używać kroków wbudowanych w Pipeline lub dostarczonych przez wtyczki. Oba mogą korzystać z bibliotek współdzielonych

Różnią się jednak składnią i elastycznością. Deklaratywne ogranicza to, co jest dostępne dla użytkownika, za pomocą bardziej rygorystycznej i predefiniowanej struktury, co czyni go idealnym wyborem dla prostszych ciągów dostaw. Scripted zapewnia bardzo niewiele ograniczeń, o ile jedyne ograniczenia dotyczące struktury i składni są definiowane przez samego Groovy, a nie przez jakiekolwiek systemy specyficzne dla Pipeline, co czyni go idealnym wyborem dla zaawansowanych użytkowników i tych o bardziej złożonych wymaganiach. Jak sama nazwa wskazuje, Declarative Pipeline zachęca do deklaratywnego modelu programowania. Podczas gdy potoki skryptowe są zgodne z bardziej imperatywnym modelem programowania.

Skopiowano z https://jenkins.io/doc/book/pipeline/syntax/#compare


5
Próbowałem przenieść serię deklaratywnych zadań potokowych do potoków skryptowych, ponieważ były one „idealnym wyborem dla zaawansowanych użytkowników i tych o bardziej złożonych wymaganiach”. Dokumentacja dotycząca potoku skryptowego jest prawie zerowa. Żaden. To prawie bezużyteczne. To duża różnica, o której ludzie powinni wiedzieć.
cauchy

6
@cauchy jest ta sama dokumentacja zarówno dla potoków skryptowych, jak i deklaratywnych, ale ponieważ skrypty są przeznaczone dla zaawansowanych użytkowników, nie jest to ta, która jest wyświetlana jako pierwsza, ale cała dokumentacja zawiera zarówno dokumentację skryptową, jak i deklaratywną potoków oraz przykłady. Musisz tylko przełączyć składnię skryptu poniżej każdego przykładu dokumentacji deklaratywnego potoku
Ilhicas

1
@Ilhicas gdzie? W podręczniku użytkownika nie ma „przełączników”. Czy masz link? Nawet kroki potoku w potoku skryptowym po prostu mówią, że nie ma różnic z potokiem deklaratywnym i linkami do dokumentacji potoku deklaratywnego, co jest mylące.
cauchy

3
@cauchy przykład jenkins.io/doc/book/pipeline , poniżej znajduje się przełącznik, który prowadzi do jenkins.io/doc/book/pipeline/# , który rozszerza skryptowy odpowiednik deklaratywnego potoku
Ilhicas

Problem polega na tym, że nie czytasz poprawnie dokumentacji. „Oto przykład pliku Jenkinsa używającego składni deklaratywnego potoku - jego odpowiednik w składni skryptowej można uzyskać, klikając łącze Przełącz potok skryptowy poniżej:„ To jest w oficjalnej dokumentacji! Przeczytaj, to możesz składać takie oświadczenia… jeśli są prawdziwe…
Ilhicas

59

Kolejną rzeczą do rozważenia jest deklaratywne potoki mają krok script () . To może uruchomić dowolny potok skryptowy. Więc moim zaleceniem byłoby użycie potoków deklaratywnych, aw razie potrzeby użycie script()potoków skryptowych. Dlatego otrzymujesz to, co najlepsze z obu światów.


3
Czy masz jakieś przykłady użycia bloku script () w potoku deklaratywnym? Ten link nie ma.
user2023861

Jeśli zauważysz, że używasz kilkukrotnego scriptbloku w potoku deklaratywnym, powinieneś rozważyć użycie całego potoku skryptowego.
Kru

Preferuję potok deklaratywny w stosunku do potoków skryptowych, jak wspomniano w @CodyK. Tak, zgadzam się, że istnieją skomplikowane sytuacje, w których możemy używać potoków skryptowych. Jednak proponowanie uproszczonego planowania zawsze zmniejsza złożoność i przez większość czasu utoruje drogę do prostszego, deklaratywnego potoku.
NIK

18

Niedawno przeszedłem na deklaratywne ze skryptów z agentem kubernetes. Do lipca 2018 roku deklaratywne potoki nie miały pełnej możliwości określania podów Kubernetes. Jednak po dodaniu yamlFilekroku możesz teraz odczytać szablon poda z pliku yaml w swoim repozytorium.

Dzięki temu możesz użyć np. Świetnej wtyczki kubernetes vscode do walidacji szablonu pod, a następnie wczytać go do pliku Jenkinsfile i używać kontenerów w krokach, jak chcesz.

pipeline {
  agent {
    kubernetes {
      label 'jenkins-pod'
      yamlFile 'jenkinsPodTemplate.yml'
    }
  }
  stages {
    stage('Checkout code and parse Jenkinsfile.json') {
      steps {
        container('jnlp'){
          script{
            inputFile = readFile('Jenkinsfile.json')
            config = new groovy.json.JsonSlurperClassic().parseText(inputFile)
            containerTag = env.BRANCH_NAME + '-' + env.GIT_COMMIT.substring(0, 7)
            println "pipeline config ==> ${config}"
          } // script
        } // container('jnlp')
      } // steps
    } // stage

Jak wspomniano powyżej, możesz dodawać bloki skryptów. Przykładowy szablon pod z niestandardowym jnlp i dockerem.

apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave:3.23-1
    imagePullPolicy: IfNotPresent
    tty: true
  - name: rsync
    image: mrsixw/concourse-rsync-resource
    imagePullPolicy: IfNotPresent
    tty: true
    volumeMounts:
      - name: nfs
        mountPath: /dags
  - name: docker
    image: docker:17.03
    imagePullPolicy: IfNotPresent
    command:
    - cat
    tty: true
    volumeMounts:
      - name: docker
        mountPath: /var/run/docker.sock
  volumes:
  - name: docker
    hostPath:
      path: /var/run/docker.sock
  - name: nfs
    nfs:
      server: 10.154.0.3
      path: /airflow/dags

1
To najbardziej pomocna odpowiedź, jaką widziałem przez cały rok: D dzięki
Trevor Rudolph

14

deklaratywna wydaje się być bardziej przyszłościową opcją i tą, którą ludzie zalecają. jest to jedyne, które może obsługiwać Visual Pipeline Editor. obsługuje walidację. i kończy się na tym, że ma większość mocy skryptów, ponieważ w większości kontekstów możesz wrócić do skryptów. Czasami ktoś wymyśla przypadek użycia, w którym nie może zrobić tego, co chce, z deklaratywnym, ale zazwyczaj są to ludzie, którzy używają skryptów od jakiegoś czasu, a te luki w funkcjach prawdopodobnie znikną z czasem.

więcej kontekstu: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/


4
Nie ma czegoś takiego, jak bardziej przyszłościowe, służą różnym odbiorcom i celom i oba mają ten sam podstawowy system, jak stwierdzono w wielu innych odpowiedziach tutaj. Deklaratywne ogranicza użytkownika, a skrypt daje mu zbyt dużą swobodę, więc aby zastosować każdy z nich, musisz być na różnych poziomach wiedzy Jenkinsa.
Ilhicas

3
zgadzam się z Tobą. ta odpowiedź była najlepsza w czasie, gdy ją pisałem, ale cieszę się, że autorzy Jenkinsa lepiej udokumentowali różnice i dali do zrozumienia, że ​​scenariusz nie zniknie w najbliższym czasie. :)
burnettk

7

Dokumentacja Jenkinsa właściwie wyjaśnia i porównuje oba typy.

Cytując: „Scripted Pipeline oferuje ogromną elastyczność i rozszerzalność użytkownikom Jenkinsa. Krzywa uczenia się Groovy nie jest zazwyczaj pożądana dla wszystkich członków danego zespołu, więc Declarative Pipeline został stworzony, aby zaoferować prostszą i bardziej upartą składnię dla autor Jenkins Pipeline.

Oba są zasadniczo tym samym podsystemem rurociągów pod spodem. "

Przeczytaj więcej tutaj: https://jenkins.io/doc/book/pipeline/syntax/#compare


1
  1. Potok deklaratywny jest zdefiniowany w bloku oznaczonym jako „potok”, podczas gdy potok skryptowy jest zdefiniowany w „węźle”.
  2. Składnia - deklaratywny potok ma „Etapy”, „Kroki”
  3. Jeśli kompilacja się nie powiodła, deklaratywny daje możliwość ponownego uruchomienia kompilacji od tego etapu, co nie jest prawdą w przypadku opcji skryptowej
  4. Jeśli wystąpi jakikolwiek problem ze skryptem, deklaratywny powiadomi Cię, gdy tylko zbudujesz zadanie, ale w przypadku skryptu przejdzie etap, który jest „OK” i wyświetli błąd na scenie, który jest „Nie OK”

Możesz również polecić to. Bardzo dobra lektura -> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? Tab = profile


1

Mam też to pytanie, które mnie tu sprowadziło. Deklaratywny potok z pewnością wydaje się preferowaną metodą i osobiście uważam go za znacznie bardziej czytelny, ale próbuję przekonwertować zadanie Freestyle na średnim poziomie złożoności na deklaratywne i znalazłem co najmniej jedną wtyczkę, wtyczkę Build Blocker, którą nie można uruchomić nawet w bloku skryptu w kroku (próbowałem umieścić odpowiednie polecenie "blockOn" wszędzie bez powodzenia, a błąd powrotu zwykle to "Nie znaleziono takiej metody DSL 'blockOn' wśród kroków" .) Więc myślę, że obsługa wtyczek to osobny problem, nawet w przypadku bloku skryptu (ktoś proszę mnie poprawić, jeśli się mylę). Musiałem też kilka razy użyć bloku skryptu, aby uzyskać to, co uważam za proste zachowanie działają, takie jak ustawienie nazwy wyświetlanej kompilacji.

Ze względu na moje doświadczenie skłaniam się ku przerobieniu mojej pracy zgodnie ze skryptem, ponieważ wsparcie dla Declarative wciąż nie jest tam, gdzie potrzebujemy, ale jest to niefortunne, ponieważ zgadzam się, że wydaje się to najbardziej przyszłościową opcją i jest oficjalnie obsługiwana. Może przed dokonaniem wyboru zastanów się, z ilu wtyczek zamierzasz korzystać.


0

Deklaratywna Rurociąg jest o wiele lepszy do skryptów Pipeline . Deklaratywny potok jest w stanie wykonać wszystko, co może wykonać skryptowany potok, korzystając z kroku skryptu i ma wiele dodatkowych funkcji.

Co więcej, Declarative Pipeline obsługuje różne technologie, takie jak Docker czy Kubernetes (patrz tutaj ).

Deklaratywny potok jest również bardziej przyszłościowy. Jest wciąż w fazie rozwoju, a nowe funkcje, takie jak nowo wprowadzona funkcja Matrix , zostały dodane niedawno pod koniec 2019 r.

tl; dr - Declarative Pipeline może zrobić wszystko, co Scripted Pipeline, a nawet więcej.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.