web-dev-qa-db-fra.com

Comment continuer après une étape défaillante de la syntaxe déclarative du pipeline Jenkins

Je souhaite définir plusieurs étapes dans la syntaxe déclarative du pipeline Jenkins, qui peuvent continuer après l'échec de l'une d'entre elles. Je ne trouve aucune des questions existantes qui soient de véritables doublons, car elles supposent toutes ou autorisent une syntaxe scriptée.

pipeline {
    agent any
    stages {
        stage('stage 1') {
            steps {
                echo "I need to run every time"
            }
        }
        stage('stage 2') {
            steps {
                echo "I need to run every time, even if stage 1 fails"
            }
        }
        stage('stage 3') {
            steps {
                echo "Bonus points if the solution is robust enough to allow me to continue *or* be halted based on previous stage status"
            }
        }
    }
}

Pour clarifier, je ne cherche pas comment faire cela avec une syntaxe scriptée. J'essaie de comprendre si ce type de contrôle de flux est réellement pris en charge et formalisé dans une syntaxe déclarative. Pour cela, je vais essayer de définir exactement ce que je recherche:

Champs obligatoires

  • Pas d'essayer/attraper. Je ne veux pas passer en mode script ou "encapsuler" mon pipeline déclaratif dans une autre bibliothèque partagée ou un autre bloc scripté.
  • Pas de manigances post step. Je veux de véritables étapes multiples, pas une étape avec une étape post always qui contient toute ma logique

Optionnel

  • L'étape défaillante doit être reconnue comme ayant échoué; Je ne veux pas qu'une étape ratée apparaisse en vert parce qu'elle a été "sautée" ou "poursuivie".
  • Une construction avec une étape échouée doit être marquée en rouge (ou en jaune, ou tout ce qui n'est pas vert).

Apparenté mais pas suffisant 

jenkinsjenkins-pipelinejenkins-declarative-pipeline
8
dolphy

Il se peut que je manque quelque chose, mais l’idée de opinionated déclaratif, pipeline est de fournir une couverture de la plupart des cas d’utilisation simples ... Le moment où vous avez besoin de quelque chose que le avisé n’a pas couvert , vous DEVEZ avoir recours à un pipeline scripté, il ne s'agit que d'une "exigence" de "pipeline déclaratif": cela ne va pas se produire maintenant.

Quant à vos autres "exigences", elles ont très peu de sens, car l’idée est d’envelopper la laideur de bas niveau dans des bibliothèques partagées offrant aux utilisateurs des constructions telles que:

    mylib.failable_stages({
      stages {
        stage('stage 1') {
          steps {
            echo "I need to run every time"
          }
        }
        stage('stage 2') {
          steps {
            echo "I need to run every time, even if stage 1 fails"
          }
        }
        stage('stage 3') {
          steps {
            echo "Bonus points if the solution is robust enough to allow me to continue *or* be halted based on previous stage status"
          }
        }
      }
    })

Naturellement, vous devriez trouver ou mettre en œuvre une telle classe mylib et le failable_stages obtiendrait une fermeture et l'envelopperait dans divers codes de plomberie/passe-partout.

J'espère que c'est utile.

1
mvk_il