-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins 2.249.1 (aka LTS)
Parameterized-Remote-Trigger plugin 3.1.4
Debian 9 docker image from upstream
When configuring a job or a pipeline through JobDSL or Jenkinsfile the default value for maxConn isn't 1 as per documentation but 0 which causes remote triggers to time out twice - which gives a 60 seconds delay before the remote build is actually triggered.
When configuring the job in the GUI the default is 1.
Also JobDSL doesn't support setting maxConn so you need to use a configure block for that.
There's a PR to fix this issue: https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/75
[JENKINS-63819] The maxConn parameter defaults to 0 in JobDSL and Jenkinsfile
Didn't try on JobDSL, but I think it should have worked well in Jenkinsfile, or maybe you can share your snippets with me for further bug reproducing.
The problem is when you create jobs without using the GUI. Eg. the following two jobs will have a maxConn of 0:
job('microservice2') {
label('master')
parameters {
stringParam('COMMIT','','Specify commit for audit-build pipelibe to build.')
}
wrappers {
timestamps()
}
steps {
remoteTrigger('audit-build', 'audit-build') {
parameters(commitHash: '${COMMIT}', subPath: 'subsystem1')
token('audit-build')
blockBuildUntilComplete()
}
}
}
pipelineJob('microservice3') {
parameters {
stringParam('COMMIT','none','Specify commit for audit-build pipelibe to build.')
}
definition {
cps {
sandbox()
script('''\
pipeline {
agent {label "master"}
options {
timestamps()
}
stages {
stage('Trigger audit build pipeline and wait') {
steps {
triggerRemoteJob(
remoteJenkinsName: 'audit-build',
job: 'audit-build',
token: 'audit-build',
parameters: "commitHash=${COMMIT}\\nsubPath=subsystem1\\nTIMEOUT=600",
blockBuildUntilComplete: true,
)
}
}
}
}
'''.stripIndent()
)
}
}
}
Here's a log excerpt from running the above pipeline:
Running on Jenkins in /var/lib/jenkins/workspace/microservice3
[Pipeline] {
[Pipeline] timestamps
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Trigger audit build pipeline and wait)
[Pipeline] triggerRemoteJob
11:09:32 ################################################################################################################
11:09:32 Parameterized Remote Trigger Configuration:
11:09:32 - job: audit-build
11:09:32 - remoteJenkinsName: audit-build
11:09:32 - parameters: [commitHash=none, subPath=subsystem1, TIMEOUT=600]
11:09:32 - blockBuildUntilComplete: true
11:09:32 - connectionRetryLimit: 5
11:09:32 - trustAllCertificates: false
11:09:32 ################################################################################################################
11:09:43 Triggering parameterized remote job 'https://audit-build.jenkins.tools.klarna.net/job/audit-build'
11:09:43 Using globally defined 'No Authentication'
11:09:43 Triggering remote job now.
11:10:13 CSRF protection is disabled on the remote server.
11:10:43 Remote job queue number: 491391
11:10:43 Remote build started!
11:10:43 Remote build URL: https://audit-build.jenkins.tools.klarna.net/job/audit-build/123715/
11:10:43 Remote build number: 123715
11:10:43 Blocking local job until remote job completes.
and the corresponding timeout errors from the Jenkins log:
2020-10-01 09:09:42.996+0000 [id=16216] WARNING o.j.p.P.utils.HttpHelper#tryCall: fail to acquire lock because of timeout, skip locking... 2020-10-01 09:10:13.042+0000 [id=16216] WARNING o.j.p.P.utils.HttpHelper#tryCall: fail to acquire lock because of timeout, skip locking... 2020-10-01 09:10:43.100+0000 [id=16216] WARNING o.j.p.P.utils.HttpHelper#tryCall: fail to acquire lock because of timeout, skip locking... 2020-10-01 09:10:53.133+0000 [id=16216] WARNING o.j.p.P.utils.HttpHelper#tryCall: fail to acquire lock because of timeout, skip locking...
And finally I'll attach a screenshot of the ordinary job having maxConn=0: 
What you mentioned is basically a feature of JobDSL plugin, so if you want the plugin to support the maxConn option which solved your problem completely, please issue a feature request or a pull request to JobDSL plugin,
But I'll still add some checks to avoid user to set maxConn to zero.
krakan
Can't reproduce what you mentioned, I started a 2.249.1 Jenkins and generated the snippet with default configuration. As you can see,
the max conn was shown on the snippet which is configurable.
And the job finished in seconds.
The output was like
Not to mention the code snippet in the repo, which is totally configurable and works fine.