Jenkins build slave setup / messy

Dear all, I had to spend a large portion of my spare time last night in order to add a new jenkins build slave in a way that it works. What should have been very simple by following the wiki at https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup turned out into a long process of failures that still continue, see http://jenkins.osmocom.org/jenkins/job/osmo-bts-gerrit/1325/ I'm really not happy about the lack of discipline in keeping the documentation in sync - or even bothering to state in the wiki "FIXME, some stuff needs to be done which is not documented". Having very incomplete documentation that suggests something is a very easy and straight-forward task is possibly worse than having no documentation, at which point the reader/user is clear about this being a time-consuming procedure that involved manual recreation of a manual setup. We do now have "build-2.osmocom.org", which is a Ryzen 1700X eight-core CPU with 64GB RAM. It natively runs Debian 9 (stretch) and has a Debian8 build slave inside a lxc container. I've updated the wiki page, but I don't think "copy over the ~/docker directory whose contents is not under revision control and then run ./update.sh" is all that good an idea either. Adding more build slaves to a jenkins setup should be the most natural and normal thing to do. After all, the entire system is designed to scale out by adding more build slaves. I think the right process here would be to have a script that generates the build slave[s]. My preference would be to have a lxc template for it, so any new build host simply needs to lxc-create from that template. Is anyone willing to contribute in that area? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)