Minor If there is step in pipeline script with syntax error, there is error reported during the build however there is no corresponding FlowNode reported.
Here is the sample script
node {
stage 'build'
sh 'echo s1'
stage 'test'
echo 'Hello World 2'
}
parallel firstBranch: {
echo 'Hello first'
}, secondBranch: {
echo 'Hello second'
sh ssdsds
},
failFast: true
Under the parallel 'secondBranch' the step sh ssdsds is reported as failure during pipeline execution however there is no FlowNode reported corresponding to this step. Below is the error reported in the log for this failed step:
groovy.lang.MissingPropertyException: No such property: ssdsds for class: groovy.lang.Binding at groovy.lang.Binding.getVariable(Binding.java:63) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:210) 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 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:498) 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:276) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$000(CpsThreadGroup.java:78) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:185) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:183) 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)
- links to
[JENKINS-35712] Failed step doesn't show as FlowNode
Blue Ocean team seems to have some other workarounds in mind that I'm not very familiar with.
One option would be to "fail safe" and show a log if there is a failed state on job (or anything) but no corresponding step flownode. This would at least tell the user what was wrong, which is often enough.
Not ideal though...
| Workflow | Original: JNJira [ 172143 ] | New: JNJira + In-Review [ 184580 ] |
| Labels | New: blueocean x-team |
(BTW the only blue ocean workaround for this is to fall back to showing full log, none others are planned or known about).
| Component/s | New: pipeline-general [ 21692 ] |
| Component/s | Original: workflow-plugin [ 18820 ] |
Perhaps naively, I initially thought it makes sense to create a FlowNode when an exception is thrown then I realized that this is more complicated, as there isn't an easy way to recognize the origin of the exception.
This example could have been sh ssdsds() and when ssdsds() invocation throws an exception, we can't tell if that's because there's no such function, or whether this function actually exists and its execution has thrown an exception. If the point in which an exception is thrown is responsible for creating a record, then in the former case the point that invokes ssdsds() would add the record, but in the latter case the code inside ssdsds() should have done that.
Maybe it's possible to have the code that catches the exception (usually CpsBodyExecution) to create a record?