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

All stages colored red, after last stage failed.

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Given a Pipeline with a sequence of multiple stages, e.g.
      stage 'one'
      stage 'two'
      stage 'three'
      and the last one fails, in this example "three", the visualizing shows all stages in red, although only the last one failed. Expectation is that only the failed stage is colored red, and all others, that were processed successfully before, are colored green.

        Attachments

          Activity

          Hide
          danielbeck Daniel Beck added a comment -

          Could you please provide a complete pipeline that demonstrates this problem?

          Show
          danielbeck Daniel Beck added a comment - Could you please provide a complete pipeline that demonstrates this problem?
          Hide
          michaelhuettermann Michael Hüttermann added a comment -

          All tests with more than one stage where a downstream stage fails shows the behavior. One example:

             stage 'Smoke'
             parallel firstBranch: {
                  echo "one"
              }, secondBranch: {
                  echo "two"
              }
            
              stage 'Unit Test'
              sh "${mvnHome}/bin/mvn clean test -f ppom.xml"
             

          The POM file in the second stage, named ppom.xml does not exist, and thus provokes a failure.This is great! But the first stage is also colored slighly red, and, to make it more confusing, the tooltip text over the stage stages "success". The first stage was processed successfully and thus the stage should be colored green, or slight green.

          Show
          michaelhuettermann Michael Hüttermann added a comment - All tests with more than one stage where a downstream stage fails shows the behavior. One example: stage 'Smoke' parallel firstBranch: { echo "one" }, secondBranch: { echo "two" } stage 'Unit Test' sh "${mvnHome}/bin/mvn clean test -f ppom.xml" The POM file in the second stage, named ppom.xml does not exist, and thus provokes a failure.This is great! But the first stage is also colored slighly red, and, to make it more confusing, the tooltip text over the stage stages "success". The first stage was processed successfully and thus the stage should be colored green, or slight green.
          Hide
          danielbeck Daniel Beck added a comment -

          Not an expert with the Stage View, but judging from our screenshot at https://jenkins.io/images/pipeline-stage-view.png I'm pretty sure it's deliberate to indicate the pipeline runs that failed. Remember from JENKINS-33844, you may not be able to see the failing stage, so it helps to indicate which pipeline runs were successful, and which weren't.

          Show
          danielbeck Daniel Beck added a comment - Not an expert with the Stage View, but judging from our screenshot at https://jenkins.io/images/pipeline-stage-view.png I'm pretty sure it's deliberate to indicate the pipeline runs that failed. Remember from JENKINS-33844 , you may not be able to see the failing stage, so it helps to indicate which pipeline runs were successful, and which weren't.
          Hide
          michaelhuettermann Michael Hüttermann added a comment -

          OK, but I still believe that successfully passed stages should be, by definition, green, or at least light green, or green with red bars, or red with green bars, but not entirely (light) red.
          Good point: Not seeing the failing stage in long pipelines is a different point IMO though. If this is an issue for someone, you may want to consider pointing to the failed stage with additional, prominent text or any other reference, which is displayed at the most left. I assume it is directly clear that the pipeline run failed if the build itself failed thus has a red bubble in build history, thus just another link directly to the failed stage would help.

          Show
          michaelhuettermann Michael Hüttermann added a comment - OK, but I still believe that successfully passed stages should be, by definition, green, or at least light green, or green with red bars, or red with green bars, but not entirely (light) red. Good point: Not seeing the failing stage in long pipelines is a different point IMO though. If this is an issue for someone, you may want to consider pointing to the failed stage with additional, prominent text or any other reference, which is displayed at the most left. I assume it is directly clear that the pipeline run failed if the build itself failed thus has a red bubble in build history, thus just another link directly to the failed stage would help.
          Hide
          svanoort Sam Van Oort added a comment -

          Hi Micheal,
          As Daniel noted, this behavior is intentional; I am retagging this as an enhancement (and reducing priority) to look at if there might be a better way to indicate this graphically.

          Thanks,
          Sam

          Show
          svanoort Sam Van Oort added a comment - Hi Micheal, As Daniel noted, this behavior is intentional; I am retagging this as an enhancement (and reducing priority) to look at if there might be a better way to indicate this graphically. Thanks, Sam
          Hide
          mrose Michael Rose added a comment -

          I agree that this request is more of an enhancement than a bug. Also note that the way failing stages are displayed on a successful build is currently different from the way successful stages are displayed on a failing build. If you're looking at redesigning this, I'd say that the two scenarios should be handled similarly.

          Show
          mrose Michael Rose added a comment - I agree that this request is more of an enhancement than a bug. Also note that the way failing stages are displayed on a successful build is currently different from the way successful stages are displayed on a failing build. If you're looking at redesigning this, I'd say that the two scenarios should be handled similarly.
          Hide
          danielbeck Daniel Beck added a comment -

          the way failing stages are displayed on a successful build is currently different from the way successful stages are displayed on a failing build.

          Which is the only way this makes sense today with horizontal scrolling. There's "light red" for a successful stage of a failed overall build, and "dark red with border" for the failing stage of a failed build. "green" is used for successful stages of a successful build. These are the three possible combinations (AFAIK no failed stage in a successful build), all easily distinguishable, so you immediately know what's what.

          Show
          danielbeck Daniel Beck added a comment - the way failing stages are displayed on a successful build is currently different from the way successful stages are displayed on a failing build. Which is the only way this makes sense today with horizontal scrolling. There's "light red" for a successful stage of a failed overall build, and "dark red with border" for the failing stage of a failed build. "green" is used for successful stages of a successful build. These are the three possible combinations (AFAIK no failed stage in a successful build), all easily distinguishable, so you immediately know what's what.
          Hide
          mrose Michael Rose added a comment -

          These are the three possible combinations (AFAIK no failed stage in a successful build), all easily distinguishable, so you immediately know what's what.

          Here is an example of what I mean:

          This produces different shades of red stages:

          node('linux') {
              stage "fail"
              try {
                  sh "false"
              }
              catch(err) {
                  stage "cleanup"
                  sh "true"
              }
              stage "done"
              sh "false"
          }
          

          This produces a white failed stage and green success stage (which I agree is a problem when horizontal scrolling is needed):

          node('linux') {
              stage "fail"
              try {
                  sh "false"
              }
              catch(err) {
                  stage "cleanup"
                  sh "true"
              }
              stage "done"
              echo "done"
          }
          
          Show
          mrose Michael Rose added a comment - These are the three possible combinations (AFAIK no failed stage in a successful build), all easily distinguishable, so you immediately know what's what. Here is an example of what I mean: This produces different shades of red stages: node( 'linux' ) { stage "fail" try { sh " false " } catch (err) { stage "cleanup" sh " true " } stage "done" sh " false " } This produces a white failed stage and green success stage (which I agree is a problem when horizontal scrolling is needed): node( 'linux' ) { stage "fail" try { sh " false " } catch (err) { stage "cleanup" sh " true " } stage "done" echo "done" }
          Hide
          mscharp Michael Scharp added a comment -

          Michael Rose
          Your example is probably related to: JENKINS-34212

          Presumably a "step" that throws an error, but which is caught and thus completes the "stage" successfully should not be marked as failed. I agree it is very confusing to see a successful Pipeline with a stage marked as failed. By definition, that should be impossible...

          Show
          mscharp Michael Scharp added a comment - Michael Rose Your example is probably related to: JENKINS-34212 Presumably a "step" that throws an error, but which is caught and thus completes the "stage" successfully should not be marked as failed. I agree it is very confusing to see a successful Pipeline with a stage marked as failed. By definition, that should be impossible...
          Hide
          mrose Michael Rose added a comment -

          Failed is probably a bad term for the stage, but I think that there is still value in knowing that the stage diverged from the standard flow without having to go and look through the console output of each build.

          Show
          mrose Michael Rose added a comment - Failed is probably a bad term for the stage, but I think that there is still value in knowing that the stage diverged from the standard flow without having to go and look through the console output of each build.
          Hide
          mscharp Michael Scharp added a comment -

          If you've used a try/catch and programmed a secondary means for the stage to complete successfully, then regardless of the route (path A or path B) the stage itself is successful. If there is a need to visually see which route was taken, and I agree that this information could be useful, what way would be the best to display it without changing the meaning of stage's result? If JENKINS-33430 is implemented, the try block could execute a different stage than the catch block. Based on which stage was in the Pipeline visualization you'd know which route the pipeline took, and we'd be able to see that for historical builds too.

          Show
          mscharp Michael Scharp added a comment - If you've used a try/catch and programmed a secondary means for the stage to complete successfully, then regardless of the route (path A or path B) the stage itself is successful. If there is a need to visually see which route was taken, and I agree that this information could be useful, what way would be the best to display it without changing the meaning of stage's result? If JENKINS-33430 is implemented, the try block could execute a different stage than the catch block. Based on which stage was in the Pipeline visualization you'd know which route the pipeline took, and we'd be able to see that for historical builds too.
          Hide
          mrose Michael Rose added a comment -

          That seems like a reasonable compromise.

          Show
          mrose Michael Rose added a comment - That seems like a reasonable compromise.
          Hide
          svanoort Sam Van Oort added a comment - - edited

          There are two separate tasks here, one is that try/catch isn't handled correctly (a bug) - all discussion of that should go in JENKINS-34212.

          The other issue is a possible enhancement in how we represent the passing stages preceding a failure (this issue).

          I'd like to try to keep these two issues separate, since the first is a low-level issue, and the UI is completely styling.

          Show
          svanoort Sam Van Oort added a comment - - edited There are two separate tasks here, one is that try/catch isn't handled correctly (a bug) - all discussion of that should go in JENKINS-34212 . The other issue is a possible enhancement in how we represent the passing stages preceding a failure (this issue). I'd like to try to keep these two issues separate, since the first is a low-level issue, and the UI is completely styling.
          Hide
          jamesdumay James Dumay added a comment -

          Hi there,

          We are going to be solving a lot of similar problems to the Stage View plugin in the new Blue Ocean UI. In the case of this ticket, we do not believe Blue Ocean suffers from this issue.

          If you haven't heard of Blue Ocean yet, take a peek at the introductory blog post, install the plugin from the experimental update center and give us feedback on the Jenkins Users mailing list.

          If anyone feels like picking up this ticket in the future, please feel free to reopen it and assign it to yourself.

          Thanks,
          James

          Show
          jamesdumay James Dumay added a comment - Hi there, We are going to be solving a lot of similar problems to the Stage View plugin in the new Blue Ocean UI. In the case of this ticket, we do not believe Blue Ocean suffers from this issue. If you haven't heard of Blue Ocean yet, take a peek at the introductory blog post , install the plugin from the experimental update center and give us feedback on the Jenkins Users mailing list. If anyone feels like picking up this ticket in the future, please feel free to reopen it and assign it to yourself. Thanks, James

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            michaelhuettermann Michael Hüttermann
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: