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

archiveArtifacts step failure is not displayed

    • Pipeline - December

      I'm experiencing an issue with Blue Ocean and Stage View where a failure in the archiveArtifacts step of a pipeline correctly changes the build result variable to FAILURE; however, this does not provide Blue Ocean or Stage View with any way of determining that it failed. As far as I'm aware, these UI plugins use thrown exceptions to locate failed steps in a pipeline? If so, the archiveArtifacts step (and possibly others) should also throw exceptions instead of just updating the build result.

      A pipeline script to reproduce the behaviour:

      stage("archive-test") {
          node {
              archiveArtifacts "DoesNotExist/*"
          }
      }

       

          [JENKINS-44407] archiveArtifacts step failure is not displayed

          Jesse Glick added a comment -

          If a step fails, Pipeline internals will add an ErrorAction to that FlowNode. The rest is up to visualizations. If you are referring to a call to Run.setResult, without actually failing the step, that it entirely outside the control of Pipeline and there is no way to reconstruct when it happened. In JENKINS-38005 I asked abayer to follow up with the deletion of the whole try-block and use of AbortException, but nothing happened; possibly making those simplifications in core would solve the issue, in which case this is a core issue.

          Jesse Glick added a comment - If a step fails, Pipeline internals will add an ErrorAction to that FlowNode . The rest is up to visualizations. If you are referring to a call to Run.setResult , without actually failing the step, that it entirely outside the control of Pipeline and there is no way to reconstruct when it happened. In JENKINS-38005 I asked abayer to follow up with the deletion of the whole try -block and use of AbortException , but nothing happened; possibly making those simplifications in core would solve the issue, in which case this is a core issue.

          Jesse Glick added a comment -

          (To be clear, CoreStep just calls its delegate and passes on any error. If no exception is thrown, the step is assumed to have passed.)

          Jesse Glick added a comment - (To be clear, CoreStep just calls its delegate and passes on any error. If no exception is thrown, the step is assumed to have passed.)

          James Dumay added a comment -

          abayer recently fixed this for archive but apparently the implementation for archiveArtifacts is completely different from that step.

          James Dumay added a comment - abayer recently fixed this for archive but apparently the implementation for archiveArtifacts is completely different from that step.

          Andrew Bayer added a comment -

          jglick - so as best as I can tell, pretty much no Builder implementation throws an exception from perform for "this builder failed but not in a really bad/unexpected way" cases. This would seem to suggest that we basically can't expect any CoreStep call to result in the step being marked as failed, right? And since SimpleBuildStep#perform doesn't return a boolean (unlike the old school BuildStep#perform), we can't tell from CoreStep whether the step failed...this one looks like it may not be solvable.

          Andrew Bayer added a comment - jglick - so as best as I can tell, pretty much no Builder implementation throws an exception from perform for "this builder failed but not in a really bad/unexpected way" cases. This would seem to suggest that we basically can't expect any CoreStep call to result in the step being marked as failed, right? And since SimpleBuildStep#perform doesn't return a boolean (unlike the old school BuildStep#perform ), we can't tell from CoreStep whether the step failed...this one looks like it may not be solvable.

          James Dumay added a comment -

          this one looks like it may not be solvable

          abayer without a core change?

          James Dumay added a comment - this one looks like it may not be solvable abayer without a core change?

          Andrew Bayer added a comment -

          Even with a core change. Publishers like archiveArtifacts aren’t supposed to throw exceptions in a scenario like this, so there’s no way for it to signal failure.

          Andrew Bayer added a comment - Even with a core change. Publishers like archiveArtifacts aren’t supposed to throw exceptions in a scenario like this, so there’s no way for it to signal failure.

          James Dumay added a comment -

          abayer but it signals some sort of failure right now, otherwise the archiveArtifacts step wouldn't be able to fail today?

          Not sure what the next step is here?

          James Dumay added a comment - abayer but it signals some sort of failure right now, otherwise the archiveArtifacts step wouldn't be able to fail today? Not sure what the next step is here?

          Andrew Bayer added a comment -

          The publishers like archiveArtifacts signal failure by setting the build status. Perhaps jglick will have an idea of how we can deal with this, but at least so far, I think this can’t be fixed.

          Andrew Bayer added a comment - The publishers like archiveArtifacts signal failure by setting the build status. Perhaps jglick will have an idea of how we can deal with this, but at least so far, I think this can’t be fixed.

          James Dumay added a comment -

          Yikes thats a bit of a downer.

          James Dumay added a comment - Yikes thats a bit of a downer.

          Andrew Bayer added a comment -

          This is, at its core, the same as JENKINS-47412, so I'm going to use that for further discussion.

          Andrew Bayer added a comment - This is, at its core, the same as JENKINS-47412 , so I'm going to use that for further discussion.

            abayer Andrew Bayer
            inkychris Chris Wright
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: