[JIRA] (JENKINS-41604) Unique exception for input step abort

10 views
Skip to first unread message

crussell52@gmail.com (JIRA)

unread,
Jan 31, 2017, 4:17:01 PM1/31/17
to jenkinsc...@googlegroups.com
Chris Russell created an issue
 
Jenkins / Improvement JENKINS-41604
Unique exception for input step abort
Issue Type: Improvement Improvement
Assignee: Unassigned
Components: pipeline-input-step-plugin
Created: 2017/Jan/31 9:16 PM
Priority: Minor Minor
Reporter: Chris Russell

When using input in conjunction with milestone it is impossible to detect the difference between the user choosing to "abort" (e.g. say "no" to the prompt) and the build being abandoned because it was superseded. Both cases throw FlowInterruptedException

This makes it impossible to take meaningful actions upon the user choosing to abort that you would not want to take if the input goes un-answered.

One possible solution would be for the input-invoked Abort to throw a unique exception type which extends FlowInterruptedException.

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

crussell52@gmail.com (JIRA)

unread,
Aug 17, 2018, 12:45:01 PM8/17/18
to jenkinsc...@googlegroups.com
Chris Russell commented on Improvement JENKINS-41604
 
Re: Unique exception for input step abort

Implemented suggestions from here and other issue(s) related to challenges accurately detecting abort conditions that works reasonably well and covers detection of input rejection.  Details posted here, if it is useful to anybody else:

https://issues.jenkins-ci.org/browse/JENKINS-28822?focusedCommentId=346492&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-346492

 

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

james.hogarth@gmail.com (JIRA)

unread,
Aug 22, 2018, 7:51:02 AM8/22/18
to jenkinsc...@googlegroups.com

Andrew Bayer  "Lemme think on JENKINS-41272 and leave this sitting here for the moment."

Have you thought about this? I've got a developer who wants to access the causes for an abort but of course getCauses() on FlowInteruptedException isn't whitelisted yet by default...

 

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 25, 2019, 2:39:06 PM11/25/19
to jenkinsc...@googlegroups.com

Given JENKINS-41272 went with the approach of exposing the causes as JSON to avoid having to whitelist all causes as well, I think it would make sense to take the same approach here. If anyone still wants to work on it, I would file a new PR to add new methods to FlowInterruptedException similar to the approach in https://github.com/jenkinsci/workflow-support-plugin/pull/78.

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 25, 2019, 2:39:06 PM11/25/19
to jenkinsc...@googlegroups.com
Devin Nusbaum stopped work on Improvement JENKINS-41604
 
Change By: Devin Nusbaum
Status: In Progress Open

dnusbaum@cloudbees.com (JIRA)

unread,
Nov 25, 2019, 2:39:07 PM11/25/19
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Nov 25, 2019, 2:58:03 PM11/25/19
to jenkinsc...@googlegroups.com

exposing the causes as JSON to avoid having to whitelist all causes as well

That is also in line with what I proposed as an api step.

jxpearce@godaddy.com (JIRA)

unread,
Jan 30, 2020, 6:29:06 PM1/30/20
to jenkinsc...@googlegroups.com

I'm willing to try Devin Nusbaum's suggested fix (exposing the causes as JSON) if that still seems like the best approach

Reply all
Reply to author
Forward
0 new messages