Answers: <p>One possibility would be to place the checks for all the necessary pre-conditions (i.e. including those bits of info that would need to be published) in a separate build step 
  to be executed prior to the actual build step. </p>
  
  <p>If the checks in this preliminary step fail the build could be marked as aborted instead of failed. The aborted build would, hopefully, be a better indication that "nothing is actually wrong" (debatable, I know). </p>
  
  <p>Marking the build as aborted could maybe be done in a manner similar to these SO answers:</p>
  
  <ul>
  <li><a href="https://stackoverflow.com/a/44326216/4495081">Abort current build from pipeline in Jenkins</a></li>
  <li><a href="https://stackoverflow.com/a/42674979/4495081">Jenkins - abort running build if new one is started</a></li>
  </ul>
  
  <p>If those checks cannot be pulled in a step separated from the actual build step things are a bit more complicated: </p>
  
  <ul>
  <li>the actual build step would have to somehow be configured to not fail the job. I know it's possible for steps performed in virtual environments using the <a href="https://wiki.jenkins.io/display/JENKINS/ShiningPanda+Plugin" rel="nofollow noreferrer">ShiningPanda</a> plugin, but other types of steps do not have such capability.</li>
  <li>an additional step would have to be added after the actual build step. Its job would be to somehow determine if the actual build step failed and, if so, if failure was causing by one of those unfulfilled pre-requisite conditions (maybe by parsing the build logs, for example?), in which case it would abort the build. Otherwise it would pass or fail, depending on the actual build step outcome, to properly indicate the overall run status in Jenkins.</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2020-02-21T11:41:04.987Z
Answers: This is effectively what I went for in the end. Do a check against some criteria in the first step, then abort if the test fails. Not the 'cleanest' method, but it works well enough and the only people who'll be looking at it are myself and the rest of my team
Answers: Alistair Hardy
Answers: CC BY-SA 4.0
Answers: 2020-02-21T05:52:11.360Z
Answers: 2020-02-21T05:52:11.360Z
Answers: Dan Cornilescu
Body: <p>I've got two types of failures to account for within a Jenkins job. </p>
  
  <ol>
  <li>The job genuinely failed</li>
  <li>The job failed because of a certain bit of info hasn't been published. Nothing is actually wrong here.</li>
  </ol>
  
  <p>How do I handle the 2nd case so it shows the job did no complete, but nothing is actually wrong?</p>
  
Tags: <jenkins><jenkins-pipeline><jenkinsfile>
Title: Jenkinsfile handling an expected job failure
UserDisplayName: Alistair Hardy
ThreadText: # Jenkinsfile handling an expected job failure
  
  (Asked by: username_0 on 2020-02-20)
  
  I've got two types of failures to account for within a Jenkins job.
  
  1. The job genuinely failed
  2. The job failed because of a certain bit of info hasn't been published. Nothing is actually wrong here.
  
  How do I handle the 2nd case so it shows the job did no complete, but nothing is actually wrong?
  
  **Tags:** jenkins, jenkins-pipeline, jenkinsfile
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-02-21. Score: 1 | Accepted answer
  
  One possibility would be to place the checks for all the necessary pre-conditions (i.e. including those bits of info that would need to be published) in a separate build step
  to be executed prior to the actual build step.
  
  If the checks in this preliminary step fail the build could be marked as aborted instead of failed. The aborted build would, hopefully, be a better indication that "nothing is actually wrong" (debatable, I know).
  
  Marking the build as aborted could maybe be done in a manner similar to these SO answers:
  
  * [Abort current build from pipeline in Jenkins](https://stackoverflow.com/a/44326216/4495081)
  * [Jenkins - abort running build if new one is started](https://stackoverflow.com/a/42674979/4495081)
  
  If those checks cannot be pulled in a step separated from the actual build step things are a bit more complicated:
  
  * the actual build step would have to somehow be configured to not fail the job. I know it's possible for steps performed in virtual environments using the [ShiningPanda](https://wiki.jenkins.io/display/JENKINS/ShiningPanda+Plugin) plugin, but other types of steps do not have such capability.
  * an additional step would have to be added after the actual build step. Its job would be to somehow determine if the actual build step failed and, if so, if failure was causing by one of those unfulfilled pre-requisite conditions (maybe by parsing the build logs, for example?), in which case it would abort the build. Otherwise it would pass or fail, depending on the actual build step outcome, to properly indicate the overall run status in Jenkins.
  
  > **Comments:**
  > **username_0**: This is effectively what I went for in the end. Do a check against some criteria in the first step, then abort if the test fails. Not the 'cleanest' method, but it works well enough and the only people who'll be looking at it are myself and the rest of my team  
  
  ---
  
  