-
Improvement
-
Resolution: Unresolved
-
Critical
-
None
When a user makes an innocent mistake in pipeline script, the error message is overly intense. It contains too much information that are only relevant for a few people, and that ends up masking important information for users.
A case in point is JENKINS-33629, but I have heard similar feedback from a number of people:
groovy.lang.MissingPropertyException: No such property: scm for class: groovy.lang.Binding
at groovy.lang.Binding.getVariable(Binding.java:62)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:185)
at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:221)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:221)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:23)
at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17)
at WorkflowScript.run(WorkflowScript:16)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:62)
at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:58)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:106)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:277)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:77)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:186)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:184)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
This should really be reported as the following:
Undefined variable 'scm' at Jenkinsfile:16
The full stack trace can be hidden under the "details" button of something similar.
Attention like this makes a big difference in the impression of pipeline to new users, as everyone makes mistakes and how quickly we can get them unstuck is a critical part of the user experience.
- relates to
-
JENKINS-31838 Virtual thread dump uses phony filenames
-
- Open
-
-
-
- Open
-
[JENKINS-35308] Improve display of non-AbortException stack traces such as MissingPropertyException
| Summary | Original: Error reporting from pipeline script has to be much better | New: Improve display of non-AbortException stack traces such as MissingPropertyException |
I think even if the line number wasn't easy just having a shorter message with the undefined/missing variable would be enough of a hint for most pipelines (line numbers awesome, but perhaps one thing at a time).
| Epic Link | New: JENKINS-35396 [ 171189 ] |
| Workflow | Original: JNJira [ 171555 ] | New: JNJira + In-Review [ 184355 ] |
| Component/s | New: pipeline-general [ 21692 ] |
| Component/s | Original: workflow-plugin [ 18820 ] |
| Component/s | New: workflow-job-plugin [ 21716 ] | |
| Component/s | Original: pipeline [ 21692 ] |
| Component/s | New: workflow-cps-plugin [ 21713 ] |
Not sure how straightforward this is. Catching MissingPropertyException and specially printing it (when it is the cause for build termination) is easy enough, at least assuming it has not been wrapped in another exception, which I think is not an issue in this case. (Cf.
JENKINS-25894.) Getting the property name is also easy.Finding the source and line number is another matter. We could look for synthetic stack trace elements and print only those, but we might inadvertently wind up hiding relevant parts. Needs some study to make sure that the simplification would actually work reliably.