Skip to main content
  1. Posts/

Jenkins—Executing Shell Scripts—Handling Non-Zero Return Codes

·242 words·1 min· ·
Xianpeng Shen
Author
Xianpeng Shen
DevOps & Build Engineer | Python Enthusiast | Open Source Maintainer
Table of Contents

Jenkins Tip 3—Each installment describes a Jenkins tip using brief text and images.

Problem
#

When using a Jenkins pipeline, if a Shell command returns a non-zero value (meaning the Shell command encountered an error), the Jenkins Job defaults to marking the current stage as failed. Therefore, the entire Job also fails.

In some cases, we want the Jenkins Job to show a successful status even if the Shell command fails and returns a non-zero value.

For example: A Shell command lists files starting with fail-list-. If such files exist, the user is notified; otherwise, no notification is sent.

ls -a fail-list-*

By default, executing the above command causes the entire Job to fail.

失败 log

Solution
#

After some investigation, the following code snippet solved the problem.

stage("Send notification") {
  steps {
    script {
      def fileExist = sh script: "ls -a fail-list-* > /dev/null 2>&1", returnStatus: true
      if ( fileExist == 0 ) {
        // send email to user
      }else {
        // if not found fail-list-* file, make build status success.
        currentBuild.result = 'SUCCESS'
      }
    }
  }
}

Analysis
#

When executing the Shell command, returnStatus: true is added. This returns and saves the status code, which is then compared to 0.

If it’s not equal to 0, and currentBuild.result = 'SUCCESS' is not added, the entire Jenkins Job will still be marked as failed. Adding it artificially ignores the error and sets the Job status to success.

Related

Jenkins Multibranch Pipeline

·405 words·2 mins
Discusses the use of Jenkins Multibranch Pipeline to manage multiple branches in a project, enabling parallel builds for pull requests and efficient code review processes.

Jenkins Top 3 best practice

·906 words·5 mins
Discusses three best practices for Jenkins: Configuration as Code, Shared Libraries, and Multi-Branch Pipeline, highlighting their benefits in terms of transparency, traceability, and self-service builds.