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

Using archiveArtifacts with a non-matching pattern silently fails the build

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Jenkins 2.7.3, Pipeline 2.3

      If you happen to specify a pattern that doesn't match any files in the workspace, archiveArtifacts will silently fail the build.

      Jenkinsfile

      node {
          sh 'echo "lol"'
          
          archiveArtifacts artifacts: 'lol*.zip'
      }
      

      Console Output

      Started by user admin
      [Pipeline] node
      Still waiting to schedule task
      Waiting for next available executor
      Running on Azure0907122157 in /home/azureuser/workspace/Experiments/bad-artifacts
      [Pipeline] {
      [Pipeline] sh
      [bad-artifacts] Running shell script
      + echo lol
      lol
      [Pipeline] step
      Archiving artifacts
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      Finished: FAILURE
      

      archive step

      In contrast, the use of the archive step (e.g. archive 'lol*.zip' in the above Jenkinsfile) will result in a silently successful build.

          [JENKINS-38005] Using archiveArtifacts with a non-matching pattern silently fails the build

          Daniel Beck added a comment -

          Notably (IIRC) freestyle jobs log when a step makes the build result worse. Looks like Pipeline does not?

          Daniel Beck added a comment - Notably (IIRC) freestyle jobs log when a step makes the build result worse. Looks like Pipeline does not?

          I would like to add that it looks to me that archiveArtifacts also (silently) fails when using absolute paths:

          def myfile1 = "foobar"
          sh "echo foobar > ${myfile1}"
          archiveArtifacts artifacts: "${myfile1}", fingerprint: true
          

          works correctly,

          def myfile1 = "${WORKSPACE}/foobar"
          sh "echo foobar > ${myfile1}"
          archiveArtifacts artifacts: "${myfile1}", fingerprint: true
          

          on the other hand does not.

          Christian Beushausen added a comment - I would like to add that it looks to me that archiveArtifacts also (silently) fails when using absolute paths: def myfile1 = "foobar" sh "echo foobar > ${myfile1}" archiveArtifacts artifacts: "${myfile1}" , fingerprint: true works correctly, def myfile1 = "${WORKSPACE}/foobar" sh "echo foobar > ${myfile1}" archiveArtifacts artifacts: "${myfile1}" , fingerprint: true on the other hand does not.

          dan turner added a comment -

          bump, just spent 1/2 a day looking for this!

          dan turner added a comment - bump, just spent 1/2 a day looking for this!

          Andrew Bayer added a comment -

          PR up at https://github.com/jenkinsci/jenkins/pull/2823 with Jesse's suggested patch and a change to the error message.

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/jenkins/pull/2823  with Jesse's suggested patch and a change to the error message.

          Michael Neale added a comment -

          gosh that is terrible. The step result isn't failure, and there is no log message. 

          Michael Neale added a comment - gosh that is terrible. The step result isn't failure, and there is no log message. 

          Andrew Bayer added a comment -

          Not sure about the step result aspect - I can never remember how that actually gets set. But at a minimum, this will definitely log an error. If it turns out to still not cause the step in Blue Ocean to know it failed, we can revisit.

          Andrew Bayer added a comment - Not sure about the step result aspect - I can never remember how that actually gets set. But at a minimum, this will definitely log an error. If it turns out to still not cause the step in Blue Ocean to know it failed, we can revisit.

          Emil Styrke added a comment -

          abayer, as far as I can see, the step still shows with a green dot in "pipeline steps" view (and with a green check mark in BlueOcean). See JENKINS-45200 which I reported the other day.

          I get somewhere around 25 Mb of logs from my build, with multiple archiving steps, so even with the error message, finding out why my build failed was quite hard.

          Emil Styrke added a comment - abayer , as far as I can see, the step still shows with a green dot in "pipeline steps" view (and with a green check mark in BlueOcean). See JENKINS-45200 which I reported the other day. I get somewhere around 25 Mb of logs from my build, with multiple archiving steps, so even with the error message, finding out why my build failed was quite hard.

          Jesse Glick added a comment -

          If you continue to have an issue using Jenkins 2.59 or later please file a separate issue (linked) with steps to reproduce from scratch.

          Jesse Glick added a comment - If you continue to have an issue using Jenkins 2.59 or later please file a separate issue (linked) with steps to reproduce from scratch.

          Craig Ringer added a comment -

          The comments here about "silently" failing the build make me think it'd be very good to capture the hudson.Abort exception and its stack. Then when the pipeline aborts, print

          "Pipeline aborted. (See stack)", with "(See stack)" as a ConsoleAnnotation that lets you view the stack that led to the abort.

          Even "Pipeline aborted in 'build' step at line '42'" would be a massive help though.

          Craig Ringer added a comment - The comments here about "silently" failing the build make me think it'd be very good to capture the hudson.Abort exception and its stack. Then when the pipeline aborts, print "Pipeline aborted. (See stack)", with "(See stack)" as a ConsoleAnnotation that lets you view the stack that led to the abort. Even "Pipeline aborted in 'build' step at line '42'" would be a massive help though.

          Jesse Glick added a comment -

          ringerc as far as I know this issue is fixed, and when a Step fails with an AbortException, the log will display that message. That said, having an optional link in the (“classic”) UI to display the full stack trace from an AbortException (which is normally concealed) would be a neat enhancement for workflow-job-plugin.

          Jesse Glick added a comment - ringerc as far as I know this issue is fixed, and when a Step fails with an AbortException , the log will display that message. That said, having an optional link in the (“classic”) UI to display the full stack trace from an AbortException (which is normally concealed) would be a neat enhancement for workflow-job-plugin .

            abayer Andrew Bayer
            rtyler R. Tyler Croy
            Votes:
            9 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: