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

All stages colored red, after last stage failed.

    XMLWordPrintable

Details

    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

          danielbeck Daniel Beck added a comment -

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

          danielbeck Daniel Beck added a comment - Could you please provide a complete pipeline that demonstrates this problem?

          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.

          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.
          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.

          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.

          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.

          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.
          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

          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
          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.

          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.
          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.

          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.
          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"
          }
          
          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" }

          mrose
          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...

          mscharp Michael Scharp added a comment - mrose 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...
          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.

          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.

          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.

          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.
          mrose Michael Rose added a comment -

          That seems like a reasonable compromise.

          mrose Michael Rose added a comment - That seems like a reasonable compromise.
          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.

          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.
          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

          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
          imran033 Imran added a comment - - edited

          Need this fix in Jenkins classic UI as some organizations want to stick to classic UI only.
          Reopened this issue if anyone want to pick it.

          Thanks

          imran033 Imran added a comment - - edited Need this fix in Jenkins classic UI as some organizations want to stick to classic UI only. Reopened this issue if anyone want to pick it. Thanks

          People

            Unassigned Unassigned
            michaelhuettermann Michael Hüttermann
            Votes:
            3 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated: