2017-04-08 34 views
5

Próbuję odtworzyć równoważnik warunkowego etapu w potoku Jenkinsa za pomocą próby/catch wokół poprzedniego etapu, który następnie ustawia zmienną sukcesu, która jest używana aby uruchomić etap warunkowy.Rurociąg Jenkinsa - spróbuj złapać konkretny etap i kolejny krok warunkowy

Wygląda na to, że warto spróbować bloku catch catch, ustawiając powodzenie var na SUCCESS lub FAILED, który jest później używany jako część instrukcji when (w ramach fazy warunkowej).

Kod używam jest następująco:

pipeline { 
    agent any 
    stages { 
     try{ 
      stage("Run unit tests"){ 
       steps{ 
        sh ''' 
         # Run unit tests without capturing stdout or logs, generates cobetura reports 
         cd ./python 
         nosetests3 --with-xcoverage --nocapture --with-xunit --nologcapture --cover-package=application 
         cd .. 
        ''' 
        currentBuild.result = 'SUCCESS' 
       } 
      } 
     } catch(Exception e) { 
      // Do something with the exception 
      currentBuild.result = 'SUCCESS' 
     } 

     stage ('Speak') { 
      when { 
       expression { currentBuild.result == 'SUCCESS' } 
      } 
      steps{ 
       echo "Hello, CONDITIONAL" 
      } 
     } 
    } 
} 

Najnowszy błąd składni Otrzymuję się następująco:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
failed: 
WorkflowScript: 4: Expected a stage @ line 4, column 9. 
     try{ 

Próbowałem zostały również wiele odmian.

Czy podejmuję niewłaściwe podejście? Wydaje się to dość powszechnym wymogiem.

Dzięki.

+2

używasz deklaratywnego potoku, to nie pozwala na wykonanie Groovy kodu takiego jak 'try' /' catch'. – StephenKing

Odpowiedz

6

Może to rozwiązać problem w zależności od przeznaczenia. Etapy są uruchamiane tylko wtedy, gdy poprzednie etapy się powiodą, więc jeśli faktycznie masz dwa etapy, jak w twoim przykładzie, i jeśli chcesz, aby sekunda działała tylko wtedy, gdy pierwsza się powiedzie, chcesz zapewnić, że pierwszy etap zawodzi, gdy testy zakończą się niepowodzeniem. Łapanie zapobiegnie (pożądanej) awarii. W końcu zachowają awarię i nadal można będzie wykorzystać ją do pobrania wyników testu.

Więc tutaj, drugi etap będzie działać tylko wtedy, gdy przechodzą testy i wyniki testów będą rejestrowane niezależnie:

pipeline { 
    agent any 
    stages { 
    stage("Run unit tests"){ 
     steps { 
     script { 
      try { 
      sh ''' 
       # Run unit tests without capturing stdout or logs, generates cobetura reports 
       cd ./python 
       nosetests3 --with-xcoverage --nocapture --with-xunit --nologcapture --cover-package=application 
       cd .. 
       ''' 
      } finally { 
      junit 'nosetests.xml' 
      } 
     } 
     } 
    } 
    stage ('Speak') { 
     steps{ 
     echo "Hello, CONDITIONAL" 
     } 
    } 
    } 
} 

Zauważ, że ja rzeczywiście przy try w deklaratywnej rurociągu, ale like StephenKing says, nie możesz po prostu użyć try bezpośrednio (musisz owinąć dowolny groovy kod w kroku skryptu).