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.

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.

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

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.

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

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.

That seems like a reasonable compromise.

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.

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

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