This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Thu, Dec 06, 2018 at 11:28:53AM +0100, Harald Welte wrote: > Hi! > > I'm currently wondering why on earth we'd be running our master builds > inside docker containers on the build slaves. > > According to https://git.osmocom.org/osmo-ci/tree/jobs/master-builds.yml > we're currently building the following projects inside a container: > * openbsc.git > * osmo-bsc.git > * osmo-mgw.git > * osmo-msc.git > * osmo-sgsn.git > > but none of the others. Those are the projects that run the python-based external tests, which involve opening up VTY and CTRL ports among others, because we start up the program and interact with it on VTY and CTRL. That means each of those projects is not able to run tests more than once per slave, or we get sporadic conflicts of not being able to start the main program. That was really annoying. Another complex way would be to round robin through a range of ports or localhost addresses or something, and tweak the .cfg for each test run so that the ports never conflict :/ Or some sort of network segmenting? > p.s.: The underlying topic is that SSH agent forwarding doesn't exceed > into the docker container, and hence it is not possible to use jenkins > credentials for uploading resulting build artefacts such as the > manuals... ah yes. I think the only really good reason to build the manuals in a jenkins build that also runs 'make check' is that we want to catch asciidoc bugs in the patches submitted for the manuals. But to publish, it could make more sense to have a separate job for the manuals, i.e. build and publish the manuals from a jenkins job that does not use docker to de-collide the ports. That also doesn't need several build axes, just the one build config that enables the most software components. Why? well, that is the other complication, because we (want to) auto-generate VTY reference data from the main program. That then would also require starting the program and firing up VTY ports and avoiding conflicts. But I'm also having an idea here, that we introduce a cmdline option that directly dumps the VTY reference to stdout instead of having to connect via VTY and without opening any ports. Another idea would be to somehow run contrib/jenkins.sh in the docker, but in the jenkins job extract the generated manuals from that docker to publish them. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181206/1fe943f4/attachment.bin>