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

All stages colored red, after last stage failed.

      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.

          [JENKINS-33840] All stages colored red, after last stage failed.

          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.

          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.

          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.

          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.

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

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

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

          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.

          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.

          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.

          Michael Rose added a comment -

          That seems like a reasonable compromise.

          Michael Rose added a comment - That seems like a reasonable compromise.

          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.

          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.

          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

          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

          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

          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

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

              Created:
              Updated: