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)