We have a fairly large amount of jobs (200+), and we seem to be hitting an error around the usage of the JenkinsRule in the AbstractTaskRunner.groovy class. There is an implied limit of 180 seconds due to the JenkinsRule usage in test cases.
Run the example build with the --dry-run command, and place a sleep inside the DSL job definition to make the build wait during deployment. After 180 seconds the build will hit the TimedOutException. (A JUnit error)
Workarounds?
Possible workarounds would involve setting the system property 'jenkins.test.timeout' to extend this timeout. This does not work due to the implementation of JavaExec in the gradle-jenkins-jobdsl-plugin, this system property is not passed into the build at run time.
I don't believe we want this timeout at all, so we might be better off just setting it to 0, or a very high number.
Possible Fix
I have attempted to solve for this issue in this PR #120
A more elegant solution would be rewriting the plugin to not use javaexec and run the classes directly instead of creating a new process. I don't know if that seems necessary at this point, since a timeout should be a non-issue in this context.
Hello,
Issue
We have a fairly large amount of jobs (200+), and we seem to be hitting an error around the usage of the JenkinsRule in the AbstractTaskRunner.groovy class. There is an implied limit of 180 seconds due to the JenkinsRule usage in test cases.
See JenkinsRule.java from jenkins-test-harness.
Reproduction
Run the example build with the --dry-run command, and place a sleep inside the DSL job definition to make the build wait during deployment. After 180 seconds the build will hit the TimedOutException. (A JUnit error)
Workarounds?
Possible workarounds would involve setting the system property 'jenkins.test.timeout' to extend this timeout. This does not work due to the implementation of JavaExec in the gradle-jenkins-jobdsl-plugin, this system property is not passed into the build at run time.
I don't believe we want this timeout at all, so we might be better off just setting it to 0, or a very high number.
Possible Fix
I have attempted to solve for this issue in this PR #120
A more elegant solution would be rewriting the plugin to not use javaexec and run the classes directly instead of creating a new process. I don't know if that seems necessary at this point, since a timeout should be a non-issue in this context.