*Problem* Currently, the only status we have for an individual {{FlowNode}} (be it representing an atomic {{Step}} or a block) is whether it has an {{ErrorAction}}. Blue Ocean would like to be able to visualize other {{Result}} types (such as {{UNSTABLE}} and {{ABORTED}}) distinctly, as well as to be able to have all steps/blocks get marked as {{UNSTABLE}} or {{ABORTED}} if only one step/block actually is unstable or was aborted.
*Approach* We want to have a shared understanding of how the status system should work before we attempt a long refactor of the Pipeline status system. The first goal is to build a throwaway simulator that we can use to describe a Pipeline, the status of its steps and what the resulting stage, parallel and pipeline status should be. This is used to develop a set of scenarios that will be used to define the specification for the refactor.
Before moving onto the real changes there must be consensus among the team that this is the desired behaviour.
It took a little bit to work out for my case, but it ends up giving me what I need - stage failures look different from the successful ones. This is an acceptable short term workaround for me in order to get a good quick glance of stages which are failing.
Yin Ly: The workaround you mentioned does it mark stages in parallel also as failed and not the entire pipeline. Can you also provide us your workaround if possible. Thanks in advance.
Yin Lyy...@payrailz.com: The workaround you mentioned does it mark stages in parallel also as failed and not the entire pipeline. Can you also provide us your workaround if possible. Thanks in advance.
y...@payrailz.com[~yinly]: The workaround you mentioned does it mark stages in parallel also as failed and not the entire pipeline. Can you also provide us your workaround if possible. Thanks in advance.
I have not tried with parallel stages for different reasons. I am doubtful it would work since I had to wrap a try around each stage. It looks like parallel should wrap stages.
Hello Sam Van Oort, I don't really understand for which sprint this improvement is planned for. Last April? This issue blocks issue JENKINS-39203 which is the second most voted for open Bug on this Jira. We are a lot actively waiting for resolution! https://issues.jenkins-ci.org/browse/JENKINS-39203?jql=votes%20>%3D%2099%20AND%20Type%20%3D%20Bug%20AND%20status%20!%3D%20Closed%20AND%20status%20!%3D%20Resolved
Hello [~svanoort], I don't really understand for which sprint this improvement is planned for. Last April? This issue blocks issue JENKINS-39203 which is the second most voted for open Bug on this Jira. We are a lot actively waiting for resolution! [jql search on votes >= 99 AND Type = Bug AND status != Closed AND status != Resolved|https://issues.jenkins-ci.org/browse/JENKINS-39203?jql=votes%20>%3D%2099%20AND%20Type%20%3D%20Bug%20AND%20status%20!%3D%20Closed%20AND%20status%20!%3D%20Resolved]
In my humble opinion this is one of the basic features missing in the pipeline and should be on high priority. All the solutions that have been described previously as workarounds such as using try-catch do not work for a declarative pipeline.
As of Pipeline: API 2.34, Pipeline steps are able to use the new WarningAction API to identify that some non-fatal event occurred during the execution of a step but execution continued normally. Visualizations are able to access this new action and use them to change how visualizations are displayed. See this comment on JENKINS-39203 for additional details.