Closed nuclearsandwich closed 6 years ago
This is now in suitable shape to run this Groovy script. @gavanderhoorn if you want to give this PR another test run as well I think it should actually be working.
The config file templates we use are quite brittle and are part of the root cause for #160.
By making future configuration changes to Jenkins via Groovy scripts we can make smaller units of change than whole config files which will avoid having interleaving concerns in a single config file template that is hard to refresh.
@nuclearsandwich: these commits are part of the deployment/2018-01-18
right?
@nuclearsandwich: these commits are part of the deployment/2018-01-18 right?
yep as of about an hour ago. They actually started as https://github.com/ros-infrastructure/buildfarm_deployment/commit/0fb2ae814781d9e892155e3220e768eb08bfd3dd and https://github.com/ros-infrastructure/buildfarm_deployment/commit/6c86b46f9e3f646f1422752afc5c0033c09a6d9f and were cherry picked because I messed up my local branches.
Test deployment just finished: no errors, warnings, failures nor skips in puppet.log
. Jenkins master looks ok so far.
Seems #171, #172 and #173 are addressed by the changes in deployment/2018-01-18
.
(#177 is still an issue, but that is expected)
Would it make sense to use the same machinery to update the TCP port for JNLP agents configuration item using a groovy script?
That would resolve #177.
Would it make sense to use the same machinery to update the TCP port for JNLP agents configuration item using a groovy script?
Yes. I think that's an optimal next case. I'll make some comments there.
The jenkins::cli::exec resource is working differently from my first impression of it. Rather than use it directly, we'll adapt some of its internal machinery to our own
rosjenkins::groovy
resource.This is not quite working yet, yielding an HTTP 503 status for me. For firstrun it's even less reliable as the CLI jar placement is still an implicit dependency.