Zasady i przepisy dotyczące pracy w jenkinsach

Question

Obecnie dodajemy groovy pipeline scripts do naszej konstrukcji CI w jenkins. Niektóre elementy można zsynchronizować, niektóre zależą od wyjścia innego kroku kompilacji.

parallel "does_not_depend_on_X": { upfront_tests(); }, 
"depends_on_x": { produce_x(); integration_tests(); publish_test_results()} 

Hej! Rozumiem to! make rozwiązał to z zasadami i przepisami!

all: upfront_tests test_results x 

test_results: x 
    integration_tests > test_results 

x: x_inputs 
    produce_x $* 

upfront_test_results: 
    upfront_tests 

Czy istnieje sposób, aby osiągnąć ten skierowany acykliczny-milimetrowym Sortowanie/parallelizing z Jenkins i porywające też?

Answer 1

Muszę powiedzieć, że jest to bardzo interesujące pytanie do burzy mózgów. AFAIK nie ma sposobu na użycie tej składni. Jenkins obsługuje dwa sposoby definiowania rurociągi: skryptów rurociągi (styl nadrzędny przy użyciu Groovy) i deklaratywnych rurociągów (bardziej uporządkowany sposób), choć szczerze mówiąc nie sądzę, ten ostatni jest naprawdę deklaratywne (trzeba jeszcze zdefiniować co robić i jak to zrobić), ale może ułatwia tworzenie edytorów graficznych ze względu na uproszczoną składnię. Oba są udokumentowane here i nie znam żadnego innego sposobu ich napisania.

Należy jednak zwrócić uwagę na to, że Make (i ogólnie narzędzia do budowania) i Jenkins są bardzo różnymi narzędziami i mają zastosowanie do bardzo różnych scenariuszy. Make jest narzędziem do kompilacji programu (głównie programów w C lub C++), natomiast Jenkins jest w pełni wyposażonym mechanizmem automatyzacji CI, który może być wykorzystywany do realizacji złożonych procesów ciągłego dostarczania, począwszy od realizacji transakcji SCM, a kończąc na posiadaniu uruchamianie aplikacji (zwykle po zdaniu zestawu testów) w środowisku. Jeśli narzędzia do budowania opierają się na skierowanym wykresie acyklicznym, potok Jenkinsa zasadniczo przedstawia liniowy przepływ pracy między etapami. Tak więc w pewnym sensie pomysł, by Jenkins rozszerzył Make, nie ma sensu. Nawet w narzędziach do kompilacji mają one tendencję do zmieniania zmian w sposobie ich używania. Na przykład Maven i Gradle nie mają koncepcji zależności lub warunku wstępnego, który ma Ant lub Make. Wciąż wiedzą, w jakiej kolejności wykonywać zadania, ale użytkownik nie musi ich wyraźnie określać.

Inną sprawą jest to, że musimy cofnąć się w czasie, aby zobaczyć ideę zasad Makefile. Są sposobem, aby powiedzieć, które pliki skompilować na podstawie których pliki źródłowe zostały zmodyfikowane, z zamiarem uniknięcia pełnej kompilacji w dużym projekcie. Zasadniczo zależność w Make jest po prostu plikiem źródłowym do sprawdzenia pod kątem czasu ostatniej modyfikacji. W Jenkins, oprócz kroków generujących pliki docelowe z plików źródłowych, pojęcie to nie istnieje.

Teraz można się spierać, że Jenkins może nadal używać pojęcia zależności, aby stanowić wstępny zestaw czynności, które należy wykonać przed wykonaniem bieżących, a nie tylko plików źródłowych do sprawdzenia, kiedy zostały zmodyfikowane. Innymi słowy, możemy mieć deklaratywne rurociąg zapisać jako:

pipeline { 
    agent any 

    stages {    
     stage(name='Test', depends='Build'){ 
      steps { 
       sh 'make check' 
       junit 'reports/**/*.xml' 
      } 
     } 
     stage('Build') { 
      steps { 
       sh 'make' 
      } 
     } 
     stage(name='Deploy', depends='Test') { 
      steps { 
       sh 'make publish' 
      } 
     } 
    } 
} 

Chociaż teoretycznie byłoby to zrobić składnia jeszcze bardziej deklaratywny (jak kolejność etapów w kodzie nie ma już znaczenia), to jest praktycznie bezużyteczny cecha ponieważ kolejność wystarcza do reprezentowania sekwencji etapów.