Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-32059

Workflow script echo back should have line number

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Workflow plugin echos back steps as they get executed, which is good.

      But it would be even better if this includes the line number and source file name (that is, source location) so that it's less ambiguous.

        Attachments

          Issue Links

            Activity

            kohsuke Kohsuke Kawaguchi created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue is blocking JENKINS-28119 [ JENKINS-28119 ]
            jglick Jesse Glick made changes -
            Epic Link JENKINS-35396 [ 171189 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 167535 ] JNJira + In-Review [ 182776 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            jglick Jesse Glick made changes -
            Component/s workflow-cps-plugin [ 21713 ]
            Component/s pipeline [ 21692 ]
            Hide
            jglick Jesse Glick added a comment -

            More generally, contrary to JENKINS-35308, there are missing line numbers in errors. For example, if a tool step fails buried deep in some library, you just see

            [Pipeline] End of Pipeline
            ERROR: No tool named … found
            Finished: FAILURE
            

            Even the ErrorAction in the workflow/*.xml corresponding to the FlowEndNode is not helpful here:

                <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin="workflow-api@2.1">
                  <error class="hudson.AbortException">
                    <detailMessage>No tool named null found</detailMessage>
                    <stackTrace>
                      <trace>org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:137)</trace>
                      <trace>org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:111)</trace>
                      <trace>org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52)</trace>
                      <trace>hudson.security.ACL.impersonate(ACL.java:213)</trace>
                      <trace>org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49)</trace>
                      <trace>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)</trace>
                      <trace>java.util.concurrent.FutureTask.run(FutureTask.java:266)</trace>
                      <trace>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)</trace>
                      <trace>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)</trace>
                      <trace>java.lang.Thread.run(Thread.java:745)</trace>
                    </stackTrace>
                    <suppressedExceptions class="java.util.Collections$UnmodifiableRandomAccessList" resolves-to="java.util.Collections$UnmodifiableList">
                      <c class="list"/>
                      <list reference="../c"/>
                    </suppressedExceptions>
                  </error>
                </org.jenkinsci.plugins.workflow.actions.ErrorAction>
            

            Perhaps ErrorAction should include a second field encoding the stack trace of the StepExecution.start invocation, so we can track it back to a source line number. Or perhaps this could be added as a cause or suppressed exception in CpsStepContext.onFailure, so it appears automatically whenever printStackTrace is called, though this then breaks down when WorkflowRun.finish etc. handle AbortException specially.

            Another option is for every StepAtomNode/StepStartNode to encode a SourceLocation, which would enable the RFE originally requested here. Not clear to me how to get access to that location from DSL though. CpsThread.current().getStackTrace() perhaps?

            Show
            jglick Jesse Glick added a comment - More generally, contrary to JENKINS-35308 , there are missing line numbers in errors. For example, if a tool step fails buried deep in some library, you just see [Pipeline] End of Pipeline ERROR: No tool named … found Finished: FAILURE Even the ErrorAction in the workflow/*.xml corresponding to the FlowEndNode is not helpful here: <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin= "workflow-api@2.1" > <error class= "hudson.AbortException" > <detailMessage> No tool named null found </detailMessage> <stackTrace> <trace> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:137) </trace> <trace> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:111) </trace> <trace> org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:52) </trace> <trace> hudson.security.ACL.impersonate(ACL.java:213) </trace> <trace> org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:49) </trace> <trace> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) </trace> <trace> java.util.concurrent.FutureTask.run(FutureTask.java:266) </trace> <trace> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) </trace> <trace> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) </trace> <trace> java.lang.Thread.run(Thread.java:745) </trace> </stackTrace> <suppressedExceptions class= "java.util.Collections$UnmodifiableRandomAccessList" resolves-to= "java.util.Collections$UnmodifiableList" > <c class= "list" /> <list reference= "../c" /> </suppressedExceptions> </error> </org.jenkinsci.plugins.workflow.actions.ErrorAction> Perhaps ErrorAction should include a second field encoding the stack trace of the StepExecution.start invocation, so we can track it back to a source line number. Or perhaps this could be added as a cause or suppressed exception in CpsStepContext.onFailure , so it appears automatically whenever printStackTrace is called, though this then breaks down when WorkflowRun.finish etc. handle AbortException specially. Another option is for every StepAtomNode / StepStartNode to encode a SourceLocation , which would enable the RFE originally requested here. Not clear to me how to get access to that location from DSL though. CpsThread.current().getStackTrace() perhaps?
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-35308 [ JENKINS-35308 ]
            jequals5 Marky Jackson made changes -
            Epic Link JENKINS-35396 [ 171189 ]

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              kohsuke Kohsuke Kawaguchi
              Votes:
              3 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated: