[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: Michael Neale Priority: Major Minor Add Comment

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should A sample response json is: { "_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl", "_links": {}, "actions": [], "displayName": "Checkout", "durationInMillis": 8550, "id": "5", "result": "UNSTABLE", "startTime": "2016-10-24T10:37:04.263+1100", "state": "FINISHED", "edges": [ { "_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl", "id": "7" } ] } This is the first stage, which should have succeeded.

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale created an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2016/Oct/24 1:04 AM Priority: Major Reporter: Michael Neale When there is a build which has a stage that marks the build as unstable, all the stages are marked incorrectly as unstable vs just the unstable stage. Expected action: only the stage that marked the build is unstable should return as such. To reproduce: Build the multibranch pipeline "kzantow/failure-project" from github Look at the "michaelneale" branch Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be). This is the same in stage view as well as stage graph incidentally.

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale assigned an issue to Vivek Pandey

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Assignee: Vivek Pandey

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: Michael Neale

When there is a build which has a stage that marks the build as unstable, all the stages are marked incorrectly as unstable vs just the unstable stage. Expected action: only the stage that marked the build is unstable should return as such. To reproduce:

* Build the multibranch pipeline "kzantow/failure-project" from github * Look at the "michaelneale" branch * Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be).

This is the same in stage view as well as stage graph incidentally.

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: indian

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: indian arctic

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Sam Van Oort ideally we'd only like to show the specific stage that is unstable when the pipeline is unstable (not all stages). Is that feasible?

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: arctic tasman

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: tasman

Add Comment

[jdumay@cloudbees.com (JIRA)]

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: tasman indian

Add Comment

[vivek (JIRA)]

Vivek Pandey closed an issue as Duplicate

Its going to be fixed in JENKINS-39296, closing as duplicate.

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Vivek Pandey Status: Open Closed Resolution: Duplicate

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale reopened an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Resolution: Duplicate Status: Closed Reopened

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should This is not a duplicate, or else that other one does not fix this.

Add Comment

[vivek (JIRA)]

Vivek Pandey commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Michael Neale Sorry, yes you are right. What I fixed is all steps showing it's own status.

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

yes this one isn't blue ocean specific either it seems.

Add Comment

[vivek (JIRA)]

Vivek Pandey commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Sam Van Oort Bismuth API returns all stage's status as run's status - that is if the build is completed. StatusAndtiming.computeChunkStatus(@Nonnull WorkflowRun run, @CheckForNull FlowNode before, @Nonnull FlowNode firstNode, @Nonnull FlowNode lastNode, @CheckForNull FlowNode after) I am using this method to compute status of chunk(stage). This method however does not seem to be doing the right thing. What I expect to do is to compute status of a chunk by inferring status based on the steps run inside it. See https://github.com/svanoort/pipeline-graph-analysis-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/pipelinegraphanalysis/StatusAndTiming.java#L158. My blueocean specific (pre-bismuth) implementation used logic to compute status of stage or parallel using underlying steps and last node of parallel branch and blocked sta ge. stage/parallel is FAILURE if at least one of more node inside it failed or last node of chunk had error. stage/parallel is RUNNING if at least one step inside it running stage/parallel is FINISHED if no steps inside it are running Else if FINISHED and no error on any step or last node on the chunk had no error it was SUCCESS There doesn't seem to be a way to get ABORTED status on step so we can't really compute ABORTED stage. For all error pipeline API gives AbortException so there is no way to distinguish user aborted vs script FAILURE. For UNSTABLE result, is there way to get step level UNSTABLE state? Anyways, looks like I can't really use StatusAndTiming status APIs to get status correctly. Is this something you plan to implement, otherwise I will have to take care in blueocean code?

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

@vivek This is the expected and documented behavior - https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin#PipelineStageViewPlugin-1.6%28July18%2C2016%29 There's no way for the pipeline to identify which step set the build status to unstable, so we have to assume it was one of the otherwise successful steps.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

> There doesn't seem to be a way to get ABORTED status on step so we can't really compute ABORTED stage. For all error pipeline API gives AbortException so there is no way to distinguish user aborted vs script FAILURE. If your step is the final step of the build and the build was aborted, then your step is aborted. Otherwise you are correct: there's no way to identify a failed versus manually aborted step. I'm not sure why you're saying that the status and timing APIs are the problem here – how would you propose I work around the data model limitation?

> stage/parallel is FAILURE if at least one of more node inside it failed or last node of chunk had error.

No, a stage/parallel is a FAILURE if the final node in it had an error – otherwise the error was handled in a try/catch block. This was the same mistake that legacy Stage View made. Unfortunately Jesse Glick shot down my proposal to properly track this status in pipeline since this is not the best way to handle this. I've told Jesse Glick time and time again that our handling of status coding for steps is grossly inadequate, but still he closes proposals to add an unstable status to a step. The right way to handle this is definitely JENKINS-26522 + step-level support for its custom statuses, but unfortunately that has been blocked by Blue Ocean itself.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

> There doesn't seem to be a way to get ABORTED status on step so we can't really compute ABORTED stage. For all error pipeline API gives AbortException so there is no way to distinguish user aborted vs script FAILURE.

If your step is the final step of the build and the build was aborted, then your step is aborted.  Otherwise you are correct: there's no way to identify a failed versus manually aborted step.  I'm not sure why you're saying that the status and timing APIs are the problem here -- how would you propose I work around the data model limitation?

> stage/parallel is FAILURE if at least one of more node inside it failed or last node of chunk had error.

No, a stage/parallel is a FAILURE if the final node in it had an error -- otherwise the error was handled in a try/catch block.   This was the [same mistake that legacy Stage View made|https://issues.jenkins-ci.org/browse/JENKINS- 36523 34212 ].  Unfortunately [~jglick] shot down my proposal to properly track this status in pipeline since this is not the [best way to handle this|https://issues.jenkins-ci.org/browse/JENKINS-34212?focusedCommentId=258333&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-258333]. I've told [~jglick] time and time again that our handling of status coding for steps is grossly inadequate, but still he [closes proposals to add an unstable status to a step|https://issues.jenkins-ci.org/browse/JENKINS-26523].

The right way to handle this is definitely JENKINS-26522 + step-level support for its custom statuses, but unfortunately that has been blocked by Blue Ocean itself.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

There's no way for the pipeline to identify which step set the build status to unstable Well, if the script just ran currentBuild.result = 'UNSTABLE' or a step called Run.setResult that is true; we would need a proper implementation of JENKINS-26522. (I am only opposed to partial implementations which do not actually update at least one UI to use the capability.) More likely we would want JENKINS-27395, which is what would accomplish the actual goal specified in the initial issue description here. In fact I think this is just a duplicate. Again the issue is not implementing the step & data model, which is trivial, but deciding which UIs should interpret that data and how. For the case of ABORTED, typically this is set not due to a call to Run.setResult inside the script, but rather the program as a whole terminating with FlowInterruptedException. (That API supports any Result, but ABORTED is the most common.) In such cases you can tell where the exception was thrown by inspecting ErrorAction. Keith Zantow I would point out that this idiom from the master branch makes no sense at all. You could just delete the try and finally blocks and the result would still be FAILURE—but more easily analyzed.

Add Comment

[vivek (JIRA)]

Vivek Pandey commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Thanks Sam Van Oort. >I'm not sure why you're saying that the status and timing APIs are the problem here – how would you propose I work around the data model limitation? I didn't say StatusAndtiming is a problem. What I meant was, these API doesn't give how blueocean wants to repot per state status. For example, if overall run is UNSTABLE, this API will give UNSTABLE for all steps. Where in blueocean we want to repot per set status by computing if that step had any error or it's still running or not. >No, a stage/parallel is a FAILURE if the final node in it had an error – otherwise the error was handled in a try/catch block. This was the same mistake that legacy Stage View made. Unfortunately Jesse Glick shot down my proposal to properly track this status in pipeline since this is not the best way to handle this. Yes, makes sense.

>The right way to handle this is definitely JENKINS-26522 + step-level support for its custom statuses, but unfortunately that has been blocked by Blue Ocean itself.

I guess I need more context here, just so that blueocean can unblock it

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Jesse Glick

For the case of ABORTED, typically this is set not due to a call to Run.setResult inside the script, but rather the program as a whole terminating with FlowInterruptedException. (That API supports any Result, but ABORTED is the most common.) In such cases you can tell where the exception was thrown by inspecting ErrorAction.

Thanks, that is a proposal that might solve that aspect. I think my concern is that we're building up a set of fairly complex rules now for what is the "status" of a FlowNode. Rather than doing that, we should just add a status coding (probably JENKINS-26522) and have steps set it where needed – we can cut out so much complexity very fast, and give more data and control to the user.

> Where in blueocean we want to repot per set status by computing if that step had any error or it's still running or not.

So, we still do this with the StatusAndTiming APIs – if you want to hide the uncertain UNSTABLE assignment until there's a better mechanism for attributing it, one solution is to coerce UNSTABLE status to SUCCESS (completed) in your mapping (always legal IIRC).

> I guess I need more context here, just so that blueocean can unblock it

Primarily that Stage View would be the logical case to demo a new JENKINS-26522 API in the UI and we don't do enhancements to it generally now. However if we just did explicit status coding with this and not tags / other metadata, then that's purely a change to pipeline-graph-analysis plugin.

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Sam Van Oort no https://issues.jenkins-ci.org/browse/JENKINS-26522 would not fix it - it requires the users to do some work (likely after they have a build with test failures) - unless you mean that test reports could also use the same facility?

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

[~svanoort] no https://issues.jenkins-ci.org/browse/JENKINS-26522 would not fix it - it requires the users to do some work (likely after they have a build with test failures) - unless you mean that test reports could also use the same facility? If so (or if currentBuild.result setter would do it) then yes it might. There would be no GUI change on the blue ocean side needed to accomodate this.

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: indian

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay assigned an issue to Unassigned

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Assignee: Vivek Pandey

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Jesse Glick no I don't think this is a duplicate of having multiple test results on multiple stages (https://issues.jenkins-ci.org/browse/JENKINS-27395) - this is just about unstable status (there may or may not be tests involved, of course most of the time there is so...).

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Component/s: pipeline Component/s: blueocean-plugin

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should [~jglick] no I don't think this is a duplicate of having multiple test results on multiple stages (https://issues.jenkins-ci.org/browse/JENKINS-27395) - this is just about unstable status (there may or may not be tests involved, of course most of the time there is so...). If JENKINS-26522 was implemented, there would be no GUI change required on blue ocean at least for it to work.

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

there may or may not be tests involved There is not going to be any change to the semantics of setting currentBuild.result. That sets the overall build result, period. The (vague) proposals being floated would allow the junit step to (somehow) include a test set identifier which would “scope” the results; and/or to allow a user to explicitly mark status (and other things—badges, comments, …) on some block, probably a stage. IIUC neither would affect the behavior of existing scripts: you would need to opt in somehow.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

> There is not going to be any change to the semantics of setting currentBuild.result. This has no relationship, because it completely bypasses the flow graph to directly modify the run result (making it something of a dirty hack). JUnit would only overlap with this slightly – because it would set an explicit step status. Users want a way to set more discrete and more complex statuses on steps. Blue Ocean wants a way to do this. Rather than trying to hold back the tide, let's talk concrete proposals for how to make this happen: I'm not sure where Jesse Glick is getting "vague" from but I've laid out a concrete implementation proposal and a couple of proposed syntaxes in JENKINS-26522. Michael Neale I propose we close this one as duplicate and shuffle discussion there. Objections?

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Michael Neale To clarify: JUnit would set the explicit status coding via JENKINS-26522 on the appropriate step(s) - UNSTABLE for example. Then the status-determining logic in pipeline graph analysis plugin would pick this status coding up and apply it to appropriate step(s).

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Thanks Sam Van Oort Jesse Glick that explanation makes sense to me, I think I get it now. So yes, in that case, closing this in favour of JENKINS-26522

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale resolved as Duplicate

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Status: Reopened Resolved Resolution: Duplicate

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay reopened an issue

We are going to reopen this so the Blue Ocean team can track JENKINS-26522 and verify that it works as expected when it is completed.

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Resolution: Duplicate Status: Resolved Reopened

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Component/s: blueocean-plugin Component/s: pipeline

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: Michael Neale

NOTE this ticket is to track the linked blocking ticket for the blue ocean project. When there is a build which has a stage that marks the build as unstable, all the stages are marked incorrectly as unstable vs just the unstable stage. Expected action: only the stage that marked the build is unstable should return as such. To reproduce: * Build the multibranch pipeline "kzantow/failure-project" from github * Look at the "michaelneale" branch * Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be). This is the same in stage view as well as stage graph incidentally.

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay

NOTE this ticket is to track the linked blocking ticket for the blue ocean project.

*Problem*

When there is a build which has a stage that marks the build as unstable, all the stages are marked incorrectly as unstable vs just the unstable stage.

* Expected action: *

only the stage that marked the build is unstable should return as such.

* To reproduce : * # Build the multibranch pipeline "kzantow/failure-project" from github * # Look at the "michaelneale" branch * # Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be). This *NOTE this ticket is to track the same in stage view as well as stage graph incidentally.   linked blocking ticket for the blue ocean project*

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: James Dumay

*Problem* When there is a build which has a stage that marks the build as unstable, all the stages , parallels and steps are marked incorrectly as unstable vs rather than just the unstable stage , parallel and step that caused the Pipeline to be unstable . *Expected*

only the stage that marked the build is unstable should return as such.

*To reproduce*

# Build the multibranch pipeline "kzantow/failure-project" from github

# Look at the "michaelneale" branch

# Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be).

*NOTE this ticket is to track the linked blocking ticket for the blue ocean project*

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: James Dumay

*Problem* When there is a build which has a stage that marks the build as unstable, all the stages, parallels and steps are marked incorrectly as unstable rather than just the unstable stage, parallel and step that caused the Pipeline to be unstable. * Expected*

only the stage that marked the build is unstable should return as such.

* To reproduce*

# Build the multibranch pipeline "kzantow/failure-project" from github # Look at the "michaelneale" branch # Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be). *NOTE this ticket is to track the linked blocking ticket for the blue ocean project*

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: post-release

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: post-release up next

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay assigned an issue to Vivek Pandey

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Assignee: Vivek Pandey

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Priority: Minor Critical

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Sam Van Oort Priority: Critical Minor

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Sam Van Oort

Priority: Minor Critical

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Sorry for the updatespam – I had this confused with another similarly named bug/RFE that this appears to clone. In any case, James Dumay I would not expect this to be a trivial change since you need to rework the way statuses are tracked. Basically, you can increase priority as much as you like, but it needs a significant data model change to do it the right way. If you choose to do it the wrong way, that will have to be purely Blue Ocean side and supported, and we can make no guarantees it will remain functional in the face of future pipeline changes. If you do it the right way, it will take a while though.

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Thanks Sam Van Oort! I understand this one is a difficult one to implement and its going to take its time. Im just adjusting tickets that are important to Blue Oceans 12 month roadmap.

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: up next

Add Comment

This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)

[jdumay@cloudbees.com (JIRA)]

James Dumay updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: James Dumay Sprint: 1.1

Add Comment

[jdumay@cloudbees.com (JIRA)]

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Priority: Critical Major

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Priority: Major Minor

Add Comment

[hbedoui@vermeg.com (JIRA)]

Helmi BEDOUI commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Hello, Any updates on this issue plz? It's weird to see all build steps unstable when there is only one step failing. This is a serious issue we have with the blue ocean view

Add Comment

[jdumay@cloudbees.com (JIRA)]

James Dumay commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Helmi BEDOUI we still plan on fixing this but no ETA yet. Requires a big rework of how statuses are reporting in Pipeline, so its not as simple as it might seem.

Add Comment

[thefriendlycoder@gmail.com (JIRA)]

Kevin Phillips commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

So, we've been slowly adopting the new Pipeline APIs for all of our production builds across dozens of development teams. This build status issue is causing a very large amount of frustration and wastes a lot of developer time trying to dig through logs to deduce failure statuses. As such I'm hoping this is being considered a high-priroity item to be fixed regardless of how difficult it may be to do.   That small rant aside, might I suggest that if the "correct" fix for this turns out to be something incredibly complex and difficult - which, again, suggests that it may be months or years before it is fixed - could you not find some reasonable substitution or workaround for the problem in the meantime? Like, for example, could you perhaps create a clone of the `stage()` function that maybe ignores all of the current build status logic completely but allows the build status to be explicitly set using a custom variable or method, something like `currentBuild.hackStagedResult = 'SUCCESS"`? In this way users that are experiencing this pain point would have some temporary workaround to ease the current pain while allowing you some time to fix the underlying problem correctly. NOTE: I'd even be happy if these "hacks" or "workarounds" were simply undocumented features that you put in place as temporary workarounds to this specific JIRA issue, with the expectation that once the underlying problems are fixed the "undocumented" functionality will simply be removed - and hence, no need to be maintained going forward. Thoughts?

Add Comment

[thefriendlycoder@gmail.com (JIRA)]

Kevin Phillips edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

So, we've been slowly adopting the new Pipeline APIs for all of our production builds across dozens of development teams. This build status issue is causing a very large amount of frustration and wastes a lot of developer time trying to dig through logs to deduce failure statuses. As such I'm hoping this is being considered a high-priroity item to be fixed regardless of how difficult it may be to do.

That small rant aside, might I suggest that if the "correct" fix for this turns out to be something incredibly complex and difficult - which, again, suggests that it may be months or years before it is fixed - could you not find some reasonable substitution or workaround for the problem in the meantime? Like, for example, could you perhaps create a clone of the `stage()` function , say, `manualStatusStage()`, that maybe ignores all of the current build status logic completely but allows the build status to be explicitly set using a custom variable or method, something like `currentBuild.hackStagedResult = 'SUCCESS"`? In this way users that are experiencing this pain point would have some temporary workaround to ease the current pain while allowing you some time to fix the underlying problem correctly.

NOTE: I'd even be happy if these "hacks" or "workarounds" were simply undocumented features that you put in place as temporary workarounds to this specific JIRA issue, with the expectation that once the underlying problems are fixed the "undocumented" functionality will simply be removed - and hence, no need to be maintained going forward. Thoughts?

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Kevin Phillips Believe me, we know exactly how irritating these limitations of the Pipeline architecture are because we "drink our own champagne" internally and use test result reporting extensively in Jenkins Pipelines. The problem is that this is directly tied to the limitations of the Pipeline data model, which internally is pass/fail – everything else is computed in a logical way on the basis of ErrorActions, Input Actions, whether or not the FlowNode in question is the tip of a incomplete build (In-progress). Anything that modifies how we store status is unfortunately a permanent change because it would have to work by recording data in the model, either by Actions on FlowNodes, or by some internal state, or both. Thus any "hacks" we added would be a part of Pipeline forever – we could ignore the extra data but it would introduce compatibility issues. The extra level of complexity is that any behavior needs to be consistent across (potentially nested) parallels, nested blocks, and has to have something like a try/catch construct to let users override results – which has to behave logically in the face of a full & potentially complex graph structure. Take a look at Pipeline Graph Analysis plugin and you'll see what I mean about the complexity (also the APIs for working with the graph in https://github.com/jenkinsci/workflow-api-plugin/tree/master/src/main/java/org/jenkinsci/plugins/workflow/graphanalysis). The simple fix would be to simply not display an UNSTABLE status at the UI level in any situation for Pipelines, only at the overall build level. Would that be preferred? Because that's a change we can do without too much extra hassle.

Add Comment

[lqb@yomolo.com (JIRA)]

Ruben Perez commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Then your architecture is wrong. It cannot support something fundamentally needed. The sooner you change it, the better. This project goes nowhere without this.

Add Comment

[ernst@ernstdehaan.com (JIRA)]

Ernst de Haan commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Kevin Phillips Perhaps someone (you or someone else) can implement such a “hack” as a plugin – probably with a fat disclaimer indicating that many of the scenarios (as mentioned by Sam Van Oort) are not covered. That would at least reduce the pain a bit, and it would “buy some time” to get the real solution in place. Sam Van Oort: Your suggestion to

[…] simply not display an UNSTABLE status at the UI level in any situation […]

may be of help to some people, for whom it may make sense to support that with an configuration flag somewhere. But for many (including myself) this would not add much value, if any.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Ruben Perez It is a high priority to address this and in my personal upcoming work, but right now the highest priority is ensuring Pipeline does not cause system stability problems. As far as the architecture: I took the time to write up a detailed explanation of the situation in hopes it might lead to something productive (maybe even a PR), and it really is not constructive to simply say "your architecture is wrong." While you're entitled to your opinion, let me ask you this: how would you feel if you were putting many of your nights and weekends into improving something and someone said that to you? This is an open source project and we only have so many engineers no matter how hard we work – if you think you could improve upon the architecture you're more than welcome to submit PRs that accomplish this goal.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Ernst de Haan

Perhaps someone (you or someone else) can implement such a “hack” as a plugin – probably with a fat disclaimer indicating that many of the scenarios (as mentioned by Sam Van Oort) are not covered

I was actually going to suggest that. Some of those experiments can provide new ideas for how to implement a comprehensive feature – and if they work really well they may even be requested to directly merge into the core of Pipeline. More often they provide inspiration that leads one of us to hack out the ultimate solution. Personally, I absolutely hate that we can't easily address this improvement, but past lessons have also taught us that a maintainable and robust solution is much better for this kind of challenge than a quick-and-dirty solution that opens up problems down the road. Maybe someone will be able to come up with a solution that does not impose those risks though.

Add Comment

[aramachandrakamath@gmail.com (JIRA)]

Ramachandra Kamath Arbettu updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: Ramachandra Kamath Arbettu {panel:title=Improvement on roadmap|titleBGColor=#3878de |titleColor=white } This improvement is on the Blue Ocean project roadmap. Check the [roadmap page|https://jenkins.io/projects/blueocean/roadmap/] for updates. {panel} *Problem* When there is a build which has a stage that marks the build as unstable, all the stages, parallels and steps are marked incorrectly as unstable than just the unstable stage, parallel and step that caused the Pipeline to be unstable. *To reproduce*

# Build the multibranch pipeline "kzantow/failure-project" from github # Look at the "michaelneale" branch # Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be).

Add Comment

[jenkins@ghenzler.de (JIRA)]

Georg Henzler updated an issue

Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should

Change By: Georg Henzler Attachment: overall-success-but-some-stages-marked-as-red.png

Add Comment

[jenkins@ghenzler.de (JIRA)]

Georg Henzler commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

> This build status issue is causing a very large amount of frustration and wastes a lot of developer time trying to dig through logs to deduce failure statuses

Kevin Phillips we have had the same issue. Today we work extensively with Slack notifications that contain links to html reports (this is more important than just showing the correctly coloured box anyway, because even with that the developer would still have to check the log file for the actual root cause).  In general I think it is great to have a per-pipeline-run build status - this probably shouldn't even be refactored: There are quite some use cases that need that: Notifications to source control if a feature branch can be merged, notifications about "back to normal", just showing a color in the build list in the left panel. That said I think it would be great to have additionally a per stage status, but not only for success/unstable/failed but with a much richer data model - it could e.g. be a list of info, warn and error messages that can be reduced to info/warn/error counts and even more reduced to success/unstable/failed per stage. If that was implemented as stage.info(...), stage.warn(...), stage.error(...) it could under the hood automatically set the per-pipeline-run build status. Plugins could without hassle one by one switch to the new way of setting the build status (while the old way stays intact). All that being said, if for a certain use case it is really important to only "change the color of one box", there is currently one way to achieve it: stage('Stage 1') { echo "green" } try {   stage('Stage 2') { throw new IllegalStateException("a failed stage") } } catch(err) { echo "made the stage only red" } stage('Stage 3') { echo "green" } try {   stage('Stage 4') {  throw new IllegalStateException("a failed stage") } } catch(err) { echo "made the stage only red" } stage('Stage 5') { echo "green" } Will get you Sam Van Oort As people's grief lies mostly in the UI presentation as it seems (and not in the underlying data model), maybe it could be a very simple change in the pipeline core plugin to show yellow for a a predefined exception?

Add Comment

[jenkins@ghenzler.de (JIRA)]

Georg Henzler edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

> bq.  This build status issue is causing a very large amount of frustration and wastes a lot of developer time trying to dig through logs to deduce failure statuses [~leedega] we have had the same issue. Today we work extensively with [Slack notifications|https://wiki.jenkins.io/display/JENKINS/Slack+Plugin] that contain links to [html reports|https://wiki.jenkins.io/display/JENKINS/HTML+Publisher+Plugin] (this is more important than just showing the correctly coloured box anyway, because even with that the developer would still have to check the log file for the actual root cause).

In general I think it is great to have a per-pipeline-run build status - this probably shouldn't even be refactored: There are quite some use cases that need that: Notifications to source control if a feature branch can be merged, notifications about "back to normal", just showing a color in the build list in the left panel. That said I think it would be great to have additionally a per stage status, but not only for success/unstable/failed but with a much richer data model - it could e.g. be a list of info, warn and error messages that can be reduced to info/warn/error counts and even more reduced to success/unstable/failed per stage. If that was implemented as stage.info(...), stage.warn(...), stage.error(...) it could under the hood automatically set the per-pipeline-run build status. Plugins could without hassle one by one switch to the new way of setting the build status (while the old way stays intact). All that being said, if for a certain use case it is really important to only "change the color of one box", there is currently one way to achieve it:

{code}

stage('Stage 1') { echo "green" } try {   stage('Stage 2') { throw new IllegalStateException("a failed stage") } } catch(err) { echo "made the stage only red" } stage('Stage 3') { echo "green" } try {   stage('Stage 4') {  throw new IllegalStateException("a failed stage") } } catch(err) { echo "made the stage only red" } stage('Stage 5') { echo "green" }

{code} Will get you !overall-success-but-some-stages-marked-as-red.png|thumbnail! [~svanoort] As people's grief lies mostly in the UI presentation as it seems (and not in the underlying data model), maybe it could be a very simple change in the pipeline core plugin to show yellow for a a predefined exception?

Add Comment

[jenkins@ghenzler.de (JIRA)]

[grzegorz.zieba.ext@gigaset.com (JIRA)]

Grzegorz Zieba commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Georg Henzler Is it possible to do the same in declarative pipeline?

Add Comment

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

I'm failing to understand how this issue is any less than Critical.  It completely invalidates the result of any and every pipeline job run that has even the smallest subset of stage failures.   The problem even propagates outside of Jenkins and Blue Ocean as it leads to other plugins such as the Pipeline Githubnotify Step Plugin incorrectly setting FAILURE status on GitHub PR commit statuses set from stages in the pipeline. This issue leads to developers having to waste time and drive up frustration having to hunt through the stages of their pipeline job runs to figure out which stage actually did fail. Additionally, it's really disheartening to see that this issue is only as far as Planned on the Blue Ocean Roadmap. Surely the 116 (or more) votes and 143 (or more) watchers on this issue demonstrates how important it is for a lot of people.  Other items on the roadmap that are In Progress even, such as JENKINS-44699 don't have anywhere near as many votes and/or watchers. Is there any ETA, no matter how much of guesstimate it is, available as to how long this issue will take to be fixed?

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

[taylorp36@gmail.com (JIRA)]

Taylor Patton commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

This critical issue is maddening. It's almost as if we have to separate our pipeline into small components (jobs) like we did with freestyle jobs, for the build status reporting to make sense.

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale assigned an issue to Unassigned

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: Michael Neale Priority: Major Critical Assignee: Andrew Bayer

Add Comment

[mneale@cloudbees.com (JIRA)]

Michael Neale commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Indeed yes, it is critical. This has somehow slipped. It was looked at some time ago, but unfortunately is a HUGE amount of work as there is no way in the pipeline engine to track this information (especially not if people are using scripted pipelines, which are still popular, and were included at the time). It is not at all a small job   cc Vivek Pandey Jenn Briden this somehow has slipped off the radar. It was on the old roadmap but don't know the status of it now. Given how old it is, it may be more feasible to do this in a declarative only context now and actually be possible.

Add Comment

[brian.villanueva@nice.com (JIRA)]

Brian Villanueva commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Georg Henzler - Thanks for the suggestion on using IllegalStateException to turn single stage red. Does this work for the Blue Ocean UI as well? Michael Neale - Are you suggesting that the scope of this issue be narrowed to declarative syntax? I would imagine that many of the voters and watchers of this issue are using scripted pipelines. I know we are, as there are many advanced scenarios that simply are not feasible using declarative syntax.

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

While I can appreciate the desire for a single solution to address both Pipeline styles, if a solution for one of the styles is relatively easy while the other quite complex, let's not let the perfect be the enemy of the good here.  Please.

Add Comment

[ernst@ernstdehaan.com (JIRA)]

Ernst de Haan commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Fully agree with Brian J Murrell. But then should we split this ticket in two? Then… …one of them (declarative) could be picked up and resolved, …while the other one (scripted) could potentially be implemented on a different schedule. An additional benefit could be that when we've got the solution in place for the declarative pipeline, the challenge for implementing the fix for scripted could be reduced, because we already have a guiding implementation in place (the one for declarative).

Add Comment

[jglick@cloudbees.com (JIRA)]

Jesse Glick commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

I do not see any reason to think that this issue is specific to Declarative vs. Scripted. Nor do I think it is necessarily a “huge amount of work”. There is already an API to indicate that a step failed: ErrorAction. This is added implicitly when StepContext.onFailure is called. The overall build status is set to failed (or some other statuses, acc. to FlowInterruptedException) if the FlowEndNode is marked this way, typically because the error was not caught and handled. To set a less severe result, there is a StepContext.setResult API. Unfortunately the implementation in CpsStepContext simply sets an overall build status, which is not useful, and anyway JUnitResultsStepExecution does not call it. There could perhaps be a new action type retroactively implemented by ErrorAction, or somehow related to it, which would be added to a FlowNode when setResult is called and which just defines a getResult method. This would allow JUnitResultsStepExecution to set a per-step UNSTABLE status instead of a build result, at least optionally. (I think this would need to be opt-in for compatibility reasons, unless you declare that setting a step result also makes the build result at least as bad, which may be unwanted.) Then FlowNode.getIconColor would honor the new action, causing Pipeline Steps in the classic UI to show yellow balls where appropriate, and Blue Ocean would need to be patched to do the same.

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Is any progress being made on this issue? I don't want to sound impatient but this is a pretty seriously debilitating issue!  Way beyond even just the graphical display of an entire pipeline of stages and steps looking like it's unstable, this issue completely defeats any and all {{post { }}} block processing after the first stage failure.  Every stage block from the point of a failed stage on gets processed as unstable, preventing one from doing any kind of finer (than entire pipeline) granulated processing and/or reporting of pipelines. I now personally believe this issue to be higher than Critical and believe it to be an outright Blocker as it makes much of the usefulness of Pipelines void.  It makes me want to break my pipeline down into separate free-style jobs just so that I can get meaningful reporting and processing of jobs based on whether they are successful, unstable, failed, etc.  A bug serious enough to make one wanting to abandon Pipelines is by definition a Blocker to Pipelines.

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Is any progress being made on this issue? I don't want to sound impatient but this is a pretty seriously debilitating issue!  Way beyond even just the graphical display of an entire pipeline of stages and steps looking like it's unstable, this issue completely defeats any and all \ {{post \

{ }}} block processing after the first stage failure.  Every stage block from the point of a failed stage on gets processed as unstable, preventing one from doing any kind of finer (than entire pipeline) granulated processing and/or reporting of pipelines. I now personally believe this issue to be higher than *Critical* and believe it to be an outright *Blocker* as it makes much of the usefulness of Pipelines void.  It makes me want to break my pipeline down into separate free-style jobs just so that I can get meaningful reporting and processing of jobs based on whether they are successful, unstable, failed, etc.  A bug serious enough to make one wanting want to abandon Pipelines is by definition a *Blocker* to Pipelines.

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Is any progress being made on this issue? I don't want to sound impatient but this is a pretty seriously debilitating issue!  Way beyond even just the graphical display of an entire pipeline of stages and steps looking like it's unstable, this issue completely defeats any and all \{{post { }}} block processing after the first stage failure.  Every stage block from the point of a failed stage on gets processed as unstable, preventing one from doing any kind of finer (than entire pipeline) granulated processing and/or reporting of pipelines.

I now personally believe this issue to be higher than *Critical* and believe it to be an outright *Blocker* as it makes much of the usefulness of Pipelines void.  It makes me want to break my pipeline down into separate free-style jobs just so that I can get meaningful reporting and processing of jobs based on whether they are successful, unstable, failed, etc.  A bug serious enough to make one want to abandon Pipelines is by definition a *Blocker* to Pipelines. So, can we get a status update on this?  Is anyone actively working on it or has it been thrown back on the pile?

Add Comment

[zakharovdi@gmail.com (JIRA)]

Denis Zakharov commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Same here. Situation with post actions is very annoying for us. It's broking all logic of pipeline.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Brian J Murrell [~zaharovdi] Short term, what we can do is roll back the support for UNSTABLE status. That means you never have to worry about this "bug" because we don't try to signal that a stage somewhere set that status – we simply go back to ignoring it entirely. What do you think? In the longer-term, we're building a new Pipeline engine that will replace CPS and provide solutions to a lot of painful issues (sandboxing, lack of an integrated debugger, stability and resource-use problems) and we're planning to address the way we store Step statuses there so that this ceases to be a problem. However I can't give you a firm timeline for that yet. For those who will ask "Why isn't this super easy? Why can't it be done tomorrow?!" – the answer is: "There's nothing actually storing when we set unstable status. And storing that is deceptively complex because statuses can interact and carries a huge risk of regressions." In fact, all the statuses besides success and failure are computed based on a pretty complex and delicate process. Much, much, much more is happening under the surface than users will actually see. Andrew Bayer Would it be viable to add a custom "UNSTABLE OR HIGHER" post condition for the Declarative post conditions? I think that would resolve the part of this that seems to be serious (breaking post behaviors that expect success only).

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Denis Zakharov Brian J Murrell I've opened JENKINS-53889 which I think would resolve your biggest issue here by making it easy to catch and handle UNSTABLE statuses in declarative.

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Short term, what we can do is roll back the support for UNSTABLE status. That means you never have to worry about this "bug" because we don't try to signal that a stage somewhere set that status – we simply go back to ignoring it entirely. What do you think? Sam Van Oort What is the value of currentBuild.currentResult at various stages with this proposal? Say I have 3 parallel stages A, B, and C and A is SUCCESSful and B is UNSTABLE and C is SUCCESSful. Will I be able to determine in stage C that it is SUCCESSful even though stage B was UNSTABLE? Because that is what currently doesn't happen. Currently, as soon as B hits UNSTABLE, every stage after it is UNSTABLE even if it's not really.

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Brian J Murrell currentBuild.currentResult would be entirely unchanged. It has no representation within the Pipeline data model (it directly modifies the build). What this would do is ensure that no stages show up as "unstable" for you. Which gives you what you are asking for. If you want the ability to keep the UNSTABLE status and figure out which stage actually set it... well, see above, that's way more work than one would reasonably expect (and much riskier too). Plus it requires reworking steps that can generate that status (generally steps that process unit test results, so JUnit and others).

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Sam Van Oort So, no then, your proposal doesn't really help at all, unless there is an angle that I am missing. So to repeat the use-case:

Say I have 3 parallel stages A, B, and C and A is SUCCESSful and B is UNSTABLE and C is SUCCESSful. Will I be able to determine in stage C that it is SUCCESSful even though stage B was UNSTABLE?

And to further clarify further, the stages are parallel but A completes before B and B completes before C. I have to be able to determine in C that C was in fact successful. And I really only need to be able to do this because of this whole issue. Because the pass/fail stages cannot be determined any other way by the user, I have to post comments to the PR about which ones actually were UNSTABLE but I cannot even reliably do that if B's state is going to pollute C's state!

Add Comment

[svanoort@cloudbees.com (JIRA)]

Sam Van Oort commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Brian J Murrell Unfortunately, that and the proposed mitigation in https://issues.jenkins-ci.org/browse/JENKINS-53889 are all we've got as viable short-term solutions. It's not a matter of "polluting state" - the data Pipeline needs to figure out which of the stages set the UNSTABLE status simply isn't there, and injecting that into the current system will probably break it completely. Several other engineers and I are working on a comprehensive solution to the things that make this problem hard to solve. We've already had several top Jenkins engineers spend literally months going in circles working on find a solid implementation that solves this specific issue without causing major regressions – the pull requests are out there if you're curious. Unless someone comes up with an unexpectedly clever solution, what's left is waiting for that larger effort to wrap up and then this specific problem will be solved along the way. And that sucks, and we know it's frustrating waiting, but we're doing the best we can to get that to the point of an alpha release.

Add Comment

[jenkins@ghenzler.de (JIRA)]

Georg Henzler updated an issue

Jenkins / JENKINS-39203

All stages show up as UNSTABLE when only one stage should

Change By: Georg Henzler Attachment: example-on-how-to-mark-unstable-stages-as-visually-failed-in-stage-overview.png

Add Comment

[jenkins@ghenzler.de (JIRA)]

Georg Henzler commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should Following Jesse Glick's advice in his comment, I have digged a bit deeper into this issue and found a way to display what stages actually failed that works today without code change (still all stages show up as UNSTABLE, but the ones that have failed are marked as failed): stage('Build') { } for(int i=1; i<=7; i++) { try{ stage('Test Suite '+i) { if(Math.floor(Math.random() * 3) % 3 == 0) { throw new RuntimeException("tests failed, you would use a custom exception type here") } } } catch(/* your custom exception type here */ err) { currentBuild.result = 'UNSTABLE' } } This creates a stage view as follows: This works because the pipeline-stage-view-plugin [1] takes the exception markers into account per stage. I'm sure blue ocean could also easily show this information. [1] https://github.com/jenkinsci/pipeline-stage-view-plugin/blob/47101e971da4d16a08a4a427c3d72f92cec8ff53/ui/src/main/js/view/templates/pipeline-staged.hbs#L100

Add Comment

[stuartr@ea.com (JIRA)]

Stuart Rowe commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Georg Henzler, I currently use FlowInterruptedException to achieve the same thing. The added benefit is this exception has a Result field. I've submitted pipeline-graph-analysis-plugin#PR22 to use the FlowInterruptedException's Result to determine the Stage status rather than using FAILURE (pipeline-graph-analysis-plugin 1.7) or ABORTED (pipeline-graph-analysis-plugin 1.9).

Add Comment

[jielpe-cblv38@protonmail.com (JIRA)]

jlpinardon commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Dear all, I want to add here a user experience. The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not. I can understand that, and .. .well... users or customers are always right, isn't it ? I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS. In such a situation, have in mind that users don't want to adopt the pipeline. And actually, they are asking me to come back to something which breaks the pipeline concept. So, I don't know what is the evel of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow dor Unstable stage would be nothing else than a must have. That will really be user friendly and avoid headache for CI guys that must battle agains users .

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

This ticket now has 149 votes and 169 watchers, up from 116 and 143 only 4 months ago.  Needless to say that it's affecting a lot of people. It's also very disheartening to see such a critical issue has not made it beyond the same Planned stage on the Blue Ocean Roadmap that it was back at the beginning of September.  It's not even In Progress yet, 4+ months later. Does the Jenkins team really think this issue is that unimportant? I understand that it's complicated, but is that reason enough to not even get started on it?

Add Comment

[mlandman99@gmail.com (JIRA)]

boris ivan commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Was so excited to move our production builds to using the pipeline and blue ocean visualization. With all the stages changing from green to unstable, it's a blocker. Even posting each stage status to slack becomes misleading, in that healthy stages post unstable, and there are instances of unstable stages posting as success, that's a deal breaker right off the bat. Can I suggest a short term workaround? If there was an option in the pipeline: "stageStatus=independent" (or something like that), which worked this way, it would allow us to have control and use blue ocean until it's resolved: simply allow each stage icon to use the color/state of it's own independent activity That's it. I'm not sure if that's a flowNode or what, but whatever each icon is in any stage, they all seem to be capable (today) of executing and knowing if that execution was successful or unstable or failure or aborted. If that can simply be retained and displayed for that icon, this works for me. As far as what the overall build status ends up as in this case – if you allow us to set it at the end of the pipeline, we could code that to our own needs, based on the individual statuses per stage.

Add Comment

[jielpe-cblv38@protonmail.com (JIRA)]

jlpinardon edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Dear all, I want to add here a user experience. The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not. I can understand that, and .. .well... users or customers are always right, isn't it ? I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS.

In such a situation, have in mind that users don't want to adopt the pipeline. It is a real showstopper. And actually, they are asking me to come back to something which breaks the pipeline concept. So _So , I don't know what is the evel level of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow dor for Unstable stage stages would be nothing else than a must have. _ That will really be user friendly and avoid headache for CI guys that must battle agains against upset users ;).

Add Comment

[jielpe-cblv38@protonmail.com (JIRA)]

jlpinardon edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

Dear all, I want to add here a user experience. The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not. I can understand that, and .. .well... users or customers are always right, isn't it ? I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS.

In such a situation, have in mind that users don't want to adopt the pipeline. It is a real showstopper show-stopper . And actually, they are currently asking me to come back to something which breaks the pipeline concept. _So, I don't know what is the level of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow for Unstable stages would be nothing else than a must have._ That will really be user friendly and avoid headache for CI guys that must battle against upset users ;).

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

This ticket has added 26 more votes and 20 more watchers in just a hair over a month for a total of 175 and 189, respectively. Could somebody please provide an update on the status of this issue to those 189 watchers please?

Add Comment

[brian.murrell@intel.com (JIRA)]

Brian J Murrell edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

This ticket has added 26 more votes and 20 more watchers in just a hair over a month for a total of 175 and 189, respectively. Could somebody please provide an update on the status of this issue to those 189 watchers please?

Is this *+really+* (after all of this time and attention) still just in the {color:#4c9aff}Planned{color} state that the  [Blue Ocean Roadmap|https://jenkins.io/projects/blueocean/roadmap/] indicates?

Add Comment

[yairy6@gmail.com (JIRA)]

‪yair yavneel‬‏ commented on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

this is necessary to enhance the pipeline status view, to be able to mark each stage status separately, to identify which of them if passed, unstable or failed.  It is should not Jenkins's decision to abort the pipeline or not.  what if there are independent stages? what if I want to continue and just be aware about test/stage that was failed? I think the status and the abort action should be performed explicitly.  for example - stage function that received 3 arguments: 1 - stage status (mandatory) 2 - Boolean if need to abort (optional - default to continue) 3 - message to be print in the stage view window (optional) it is will be very helpful.

Add Comment

[yairy6@gmail.com (JIRA)]

‪yair yavneel‬‏ edited a comment on JENKINS-39203

Re: All stages show up as UNSTABLE when only one stage should

this is necessary to enhance the pipeline status view, to be able to mark each stage status separately, to identify which of them if passed, unstable or failed.

It is should not be Jenkins's decision to abort the pipeline or not.

what if there are independent stages? what if I want to continue and just be aware about test/stage that was failed? I think the status and the abort action should be performed explicitly.  for example - stage function that received 3 arguments: 1 - stage status (mandatory) 2 - Boolean if need to abort (optional - default to continue) 3 - message to be print in the stage view window (optional) it is will be very helpful.

Add Comment