Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44930

Allow sh to return exit status, stdout and stderr all at once

    Details

    • Similar Issues:

      Description

      Like many of the commenters on -JENKINS-26133- I'd like to be able to capture the exit status and text written to standard out at the same time.

      My current use case is calling git merge --no-edit $branches and if there was an error sending a slack notification with the output. 

      The current workaround is:

      def status = sh(returnStatus: true, script: "git merge --no-edit $branches > merge_output.txt")
      if (status != 0) {
        currentBuild.result = 'FAILED'
        def output = readFile('merge_output.txt').trim()
        slackSend channel: SLACK_CHANNEL, message: "<${env.JOB_URL}|${env.JOB_NAME}> ran into an error merging the PR branches into the ${TARGET_BRANCH} branch:\n```\n${output}\n```\n<${env.BUILD_URL}/console|See the full output>", color: 'warning', tokenCredentialId: 'slack-token'
        error 'Merge conflict'
      }
      sh 'rm merge_output.txt'

      Which works but isn't a great developer experience... It would be great if I could request an object that contained: status, stdout, and stderr.

        Attachments

          Issue Links

            Activity

            Hide
            mlb_2010 Meghan Blanchard added a comment -

            I signed up just to be able to up-vote this ticket.  It is an incredibly fundamental requirement, I don't understand the controversy. 

            Show
            mlb_2010 Meghan Blanchard added a comment - I signed up just to be able to up-vote this ticket.  It is an incredibly fundamental requirement, I don't understand the controversy. 
            Hide
            nancyrobertson2005 Nancy Robertson added a comment -

            I like Uliul Carpatin's solution that does not break existing code.

            It or a variant thereof could also include stdErr...

            Show
            nancyrobertson2005 Nancy Robertson added a comment - I like Uliul Carpatin 's solution that does not break existing code. It or a variant thereof could also include stdErr...
            Hide
            zallenwhite Zachary White added a comment -

            This really should just return an object, probably something similar to a Process object returned by String.execute() in Groovy. That way we can access stdout, stderr, and returnValue as needed. Outputting to file as a workaround is extremely hacky and unintuitive. It also breaks down as soon as we need to write multiple outputs to the same file as a running log.

            Was trying to implement this myself via Groovy's String.execute(), up until I realized it was always executing on master. This really is expected functionality for sh, and I was surprised to find this an open issue.

            Just return an object. Override the object's toString() to give returnStatus or returnStdout options, respectively, to help support backward compatibility. Have getReturnStatus(), getStdout(), and getStderr() properties accessible on the object so we can use them as needed.

            Show
            zallenwhite Zachary White added a comment - This really should just return an object, probably something similar to a Process object returned by String.execute() in Groovy. That way we can access stdout, stderr, and returnValue as needed. Outputting to file as a workaround is extremely hacky and unintuitive. It also breaks down as soon as we need to write multiple outputs to the same file as a running log. Was trying to implement this myself via Groovy's String.execute(), up until I realized it was always executing on master. This really is expected functionality for sh, and I was surprised to find this an open issue. Just return an object. Override the object's toString() to give returnStatus or returnStdout options, respectively, to help support backward compatibility. Have getReturnStatus(), getStdout(), and getStderr() properties accessible on the object so we can use them as needed.
            Hide
            pfuntner John Pfuntner added a comment -

            My case for doing this is to have a fail or retry only under certain conditions. I have scripts that do a lot of cloud work (aws, gcp, etc) so there are transient errors sometimes where a retry might be called for. However there are also failure scenarios that are not transient and a retry would not help. By examining the exit status and output, I could determine whether or not an operation was successful, failed, or could use a retry.

            Show
            pfuntner John Pfuntner added a comment - My case for doing this is to have a fail or retry only under certain conditions. I have scripts that do a lot of cloud work (aws, gcp, etc) so there are transient errors sometimes where a retry might be called for. However there are also failure scenarios that are not transient and a retry would not help. By examining the exit status and output, I could determine whether or not an operation was successful, failed, or could use a retry.
            Hide
            monger39 David Riemens added a comment -

            My use case is an SVN operation to see if a TAG exists; here the command may return on STDOUT a revision nr if the tag exists, a warning in STDERR if the tag does not exist yet, or an error on STDERR if something went wrong. Rather than a 5 line call to sh/bat, I now have a 40 line pipeline script with retry/try/catch, storing the stdout/stderr in indvidual files, and reading them back....sigh

            Show
            monger39 David Riemens added a comment - My use case is an SVN operation to see if a TAG exists; here the command may return on STDOUT a revision nr if the tag exists, a warning in STDERR if the tag does not exist yet, or an error on STDERR if something went wrong. Rather than a 5 line call to sh/bat, I now have a 40 line pipeline script with retry/try/catch, storing the stdout/stderr in indvidual files, and reading them back....sigh

              People

              • Assignee:
                Unassigned
                Reporter:
                drewish andrew morton
              • Votes:
                131 Vote for this issue
                Watchers:
                116 Start watching this issue

                Dates

                • Created:
                  Updated: