Le moyen le plus propre de quitter prématurément un emploi au sein du pipeline Jenkins est-il une réussite?


57

J'ai un travail qui va créer des fichiers, sauf si l'une des valeurs qui lui sont fournies correspond à une valeur plus ancienne. Quel est le moyen le plus propre à Jenkins d’avorter ou de quitter le travail, sans que ce soit FAILED? Le comportement correct est correct, je veux donc que la construction soit marquée SUCCESS.

Cela aboutira à une déclaration if comme ceci;

stage ('Check value') {

     if( $VALUE1 == $VALUE2 ) {
       //if they do match exit as a success, else continue with the rest of the job 
    }

}

Je ne veux pas lancer de code d'erreur à moins que cela ne se traduise par une génération réussie.


1
Juste exit 0...
Tensibai

Je pensais que cela marquait le travail d'un échec? Si je me trompe et que vous pouvez montrer de la documentation, je serais heureux de l'accepter comme réponse
Alex

Eh bien, rien que des scripts bash, sortie 0 signifie réussite, sortie non nulle signifie échec ...
Tensibai

Ce n'est pas dans un script bash, c'est le job de pipeline lui-même, donc Groovy. Est-ce que ça change les choses?
Alex

Je pense que dans Groovy, je voudrais simplement essayer un return 0code génial qui ne lance pas une exception. Je vais laisser quelqu'un qui a plus de connaissances sur jenkins 2 confirmer ou être infirme
Tensibai

Réponses:


48

Deviner. En dehors de toute étape (sinon cela mettra fin à l'étape en tant que succès), procédez comme suit:

if( $VALUE1 == $VALUE2 ) {
   currentBuild.result = 'SUCCESS'
   return
}

return arrêtera l’étape ou le nœud sur lequel vous êtes en cours d’exécution, c’est pourquoi il est important de l’exécuter en dehors de l’étape, alors que le réglage currentBuild.resultempêche son échec.


le simple fait de rentrer devrait laisser la construction avec un statut grisé et aucun résultat ... donc pas tout à fait la même chose qu'une construction qui a échoué.
Drewish

1
Comment revenez-vous et sautez toutes les étapes restantes?
Jess Bowers

1
@ JessBowers, c'est l'endroit où vous placez l'extrait de code. Si vous le faites au niveau du nœud plutôt qu'au niveau de la scène, le travail entier sera terminé.
Alex

4
S'il vous plaît noter que cela ne fonctionne que pour le pipeline scénarisé, pas déclarative
kagarlickij

@kagarlickij - Les pipelines déclaratifs corrects n'existaient pas lorsque cette réponse a été écrite!
Alex

11

Vous pouvez également utiliser error pour quitter l'étape actuelle. Vous n'avez donc pas à tenir compte de la hiérarchie de l'étape actuelle et des éléments similaires:

def autoCancelled = false

try {
  stage('checkout') {
    ...
    if (your condition) {
      autoCancelled = true
      error('Aborting the build.')
    }
  }
} catch (e) {
  if (autoCancelled) {
    currentBuild.result = 'SUCCESS'
    // return here instead of throwing error to keep the build "green"
    return
  }
  // normal error handling
  throw e
}

Mais cela conduirait à une étape rouge si l'erreur se produit dans une étape.

entrez la description de l'image ici

Cela dépend de vos besoins, de la manière que vous souhaitez utiliser.


Si vous envisagez de le faire de cette façon, créez une nouvelle sous-classe RuntimeExceptionou lancez-la au lieu de devoir intercepter toutes les exceptions et de vérifier un drapeau
Michael Mrozek

1

Honnêtement, vous ne devriez pas avoir besoin d'utiliser spécifiquement la commande exit, mais il existe un plug-in BuildStep conditionnel pouvant aboutir au même résultat final (code qui ne s'exécute pas).

Je ne me suis pas encore heurté à cela, donc je n'ai pas utilisé le plugin.

Il existe également des conditions telles que trouvées dans cet article antérieur sur Stack Overflow sur Jenkins: Jenkins Pipeline Conditional Condition / Stage


1
Bien que votre réponse semble être valide (je ne l'ai pas vérifiée en direct depuis que j'ai trouvé une autre solution de contournement), je ne pense pas que "Honnêtement, vous ne devriez pas quitter" est un bon moyen de commencer. il est clair que l'existence de ces méthodes signifie qu'il est parfois nécessaire de sortir.
Alex

Que suggérerais-tu? Passer à une déclaration finale? Ajout du qualificatif "généralement"? Vous avez fourni des «commentaires», mais il n’est pas facile pour moi de dire l’intention ou l’action, veuillez être moins concis.
MrMesees

Attends un peu. Est-ce votre question? Si c'est le cas, TBH, vous ne voudriez pas entendre dire que vous ne devriez pas quitter, mais aucune des méthodes que j'ai suggérées ne fournit de sorties, elles contournent le code en cours d'exécution ... Soutenant directement ma position.
MrMesees

1
Ahh je vois, je pense que j'ai mal interprété votre déclaration comme "faire quelque chose pour mettre fin au travail est mauvais" au lieu de "vous ne devriez pas utiliser la exitcommande littérale " - si donc je m'excuse, c'est mon malentendu.
Alex

3
J'ai essayé de le rendre plus clair, pas besoin de vous excuser du tout, la langue est une bête volage, surtout sur internet :)
MrMesees

0

Cette Executor.interrupt(Result)méthode est le moyen le plus propre et le plus direct que j'ai pu trouver pour arrêter une construction prématurément et la marquer comme un succès.

script {
    currentBuild.getRawBuild().getExecutor().interrupt(Result.SUCCESS)
}

Avantages :

  • Fonctionne aussi bien dans un pipeline déclaratif que dans un script.
  • Pas d'essayer / attraper ou des exceptions à gérer.
  • Marque l'étape d'appel et toutes les étapes successives comme vert / passant dans l'interface utilisateur.

Inconvénients :


Pour moi ça ne marche pas - des étapes consécutives sont en cours d'exécution.
Łukasz K
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.