Potok skryptowy Jenkinsa lub potok deklaratywny

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.

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

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.

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

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/

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. 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

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ć.

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.