Reduce depth of Closures being called
#762
Conversation
| script.withEnv(inputEnv) { | ||
| body.call() | ||
| } | ||
| def submitted = script.input(message: input.message, id: input.id, ok: input.ok, submitter: input.submitter, |
| import org.jenkinsci.plugins.workflow.cps.CpsScript; | ||
|
|
||
|
|
||
| @Deprecated |
There was a problem hiding this comment.
Implemented in a few other plugins:
kubernetesdockerdocker-workflowamazon-ecs
|
I presume a timeout in (Linux only; already skipped on Windows for being too slow.) |
…lly, but 192s in CI even when passing, close to the limit
| @Issue("JENKINS-47363") | ||
| // Give this a longer timeout | ||
| @Test(timeout=5 * 60 * 1000) | ||
| @Test(timeout=10 * 60 * 1000) |
There was a problem hiding this comment.
And now it is passing in 98s. 🤷
|
This is listed as a breaking change in the release notes, but the details are shady. Can you please clarify whether it's safe to upgrade this plugin for users using docker-workflow or not? And what's the game plan otherwise. |
|
@felipecrs if all goes well, jenkinsci/docker-workflow-plugin#337 should release shortly. Sorry for any disruption. |
|
Got it, that's alright, no need to apologize. |
|
Just as a heads up and in case some other user searches for it, this upgrade caused ongoing builds to fail abruptly with: But new builds seems to be running fine. |
|
Good call; the plugin includes no tests of serial form ( Technically, the difficulty here is |
|
@jglick thank you very much for the detailed response. I must admit I understand little of what you say, but I got the gist: it would be very hard to keep this kind of backwards compatibility, or to avoid this disruption. |
4 participants
Output from jenkinsci/workflow-support-plugin#305 indicate that a lot of stack frames are
Closure.call. In some cases this is actually helping to structure code. In others, it is not. Two half-cheese, half-sausage pizzas are just one cheese and one sausage pizza.CloudBees-internal issue