Details
-
Type:
Improvement
-
Status: In Progress (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: workflow-basic-steps-plugin
-
Labels:
-
Similar Issues:
-
Epic Link:
Description
When a flow involves many steps, long logs, and/or many branches, it can be hard for a developer receiving a failure email (for example) to quickly see what part of the build actually failed and why. I think it would be useful for the catchError step to do a DFS search on the Throwable and its cause chain through the FlowNode graph starting at the end of the catch step, looking for ErrorAction, and setting/appending an environment variable with the URL of the LogAction. Or provide a new step to do the same. Thus you could write
def runStuff(param) { ... } try { parallel a: {runStuff 'a'}, b: {runStuff 'b'} } catch (e) { mail to: '...', subject: 'Failure!', body: "Build failed: ${errorUrl(e)}" }
and get a link to http://jenkins/job/myflow/123/flowGraph/77/console or the like, according to the actual step in one of the branches that threw the error.
Attachments
Issue Links
- depends on
-
JENKINS-32059 Workflow script echo back should have line number
-
- Open
-
- is duplicated by
-
JENKINS-38156 Need branch name and other details from parallel branches
-
- Resolved
-
- is related to
-
JENKINS-25894 Ugly reporting of errors from parallel step
-
- Resolved
-
-
JENKINS-26107 Allow stage to operate as a labelled block
-
- Closed
-
- relates to
-
JENKINS-43995 Individual Pipeline steps and stages/blocks should have Result statuses
-
- Resolved
-
- links to
just up-voted;
Me too, I have similar usecase. In our testenvironment, we run many tools, each generating a separate logfile. We have one generic log shown in the console.
If one test fails, we can see that it failed, and typically have an exception message shown in the console, but the actual (detailed) reason is hidden in one of
the detailed logs. For that reason we want to include a link to the workspace directory on the exception text, such that all the log-files are just one click away.
For the pipeline jobs that link is not easy to derive; it is hidden in one of the pipeline steps. as also indicated by Craig Ringer
My feeling says that making sure that link, or the ID is available at runtime should be possible ... right ?