[FIXED JENKINS-32144] Specify that a task was cancelled when CancellationException happens

[fbelzunc]

If a task which is in the queue is cancelled then the following stacktrace happens.

Started by user admin
parallel {
    Schedule job test
    Schedule job test2
ERROR: Failed to run DSL Script
java.util.concurrent.ExecutionException: java.util.concurrent.CancellationException
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:188)
    at java_util_concurrent_Future$get.call(Unknown Source)
    at com.cloudbees.plugins.flow.FlowDelegate$_parallel_closure6.doCall(FlowDSL.groovy:456)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:903)
    at groovy.lang.Closure.call(Closure.java:415)
    at groovy.lang.Closure.call(Closure.java:428)
    at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1379)
    at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:1351)
    at org.codehaus.groovy.runtime.dgm$170.invoke(Unknown Source)

It might be obvious for some Jenkins users that it has happened because someone or something cancelled the task on the queue, however according with my experience providing Jenkins support it is not for all the users.

https://issues.jenkins-ci.org/browse/JENKINS-32144

@reviewbybees

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[oleg-nenashev]

LGTM.
BTW I don't understand how you get the log above, because CancellationException is not an instance of Execution exception. "Failed to run DSL Script" should not happen. Could it be related to the nested build step? Is the error propagation (no-throw) configured well in such case?

Would be useful to see a unit test BTW

[fbelzunc]

@oleg-nenashev The root-cause of the issue might be fixed by JENKINS-25092 - there is already a pull request done.

Notice that the only purpose of this pull request is to provide more information to users so they can better understand what is going on.

[jenkinsadmin]

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

[oleg-nenashev]

🐝 according to the clarification. This change is positive in any case

[oleg-nenashev]

What about e.getMessage() in the log. Just for the sake of better logging

[fbelzunc]

@oleg-nenashev Is not e.printStackTrace(listener.getLogger()) enough?

[dnozay]

@fbelzunc adding a testcase will make sure there is no regression in the future. Could you please add one? thank you.

[fbelzunc]

@dnozay There is already a test case for this called testThatAbortAbortsQueuedJobs. The only thing this pull request does is to give more information. I am not sure how to check on a test that the build logs will show Failed to run DSL Script: At least one of the tasks of the buildflow was cancelled instead of the default message.

Notice that this pull request doesn't change the functionality at all.

[dnozay]

yes, you could check the log output; e.g. https://github.com/jenkinsci/build-flow-plugin/blob/master/src/test/groovy/com/cloudbees/plugins/flow/BuildTest.groovy#L186-L194

[dnozay]

@fbelzunc
Since I am currently looking for someone else to take over as a maintainer; I will not be the one merging this change. Please check http://jenkins-ci.org/pull-request-greeting.

Side note: I think introducing new features in this plugin is risky and takes away resources that could be better spent on the pipeline plugin. However, please feel free to merge if you are interested in carrying on the flag.