Rationale for having master builds in docker containers?

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/.

Harald Welte laforge at gnumonks.org
Fri Dec 7 06:46:04 UTC 2018


Hi Holger and List,

On Thu, Dec 06, 2018 at 04:26:47PM +0000, Holger Freyther wrote:
 
> I just skimmed through this thread but it seems to have the right answers.
> 
> The primary reason was being able to run multiple instances of the VTY tests
> without having to make the (test)software more complex (e.g. bind to vty
> port 0 and then parse it) (and the db paths and af_unix paths)

ok. That's very valid for gerrit builds, where it's important to be able to
build test multiple patches in parallel.  For master builds, I would argue
that this is not a real concern, as it's fine to have only one master build
per repository (e.g. osmo-bsc.git) at any given time [on any given build slave].

> Secondary reasons are making the build environment volatile 

That's of course still a valid reason, for any build, including master builds -
so we'll have to keep the dockerized builds.  However, I would argue that we
should

1) build all projects, or at least all projects that have dependencies on other
   [osmocom] projecst inside docker, not some on the build slave and some in a container

2) have a process by which the container images are re-built.  Right now those appear
   to be still jessie-based, for example.  It's good to test both jessie and stretch,
   of course, but doing some project builds on either of the two doesn't really ensure
   compatibility for both versions.  We should either build everything on both stretch
   and jessie, or one defined version.

3) ensure that gerrit and master builds run in identical environments.  This reduces
   the risk of patches passing gerrit but failing in master.

> and managing the dependencies differently.

Can you please elaborate on that?

Regarding the "deployment" of artifacts like pdf manuals or binary firmware
builds, I would say it's best to move that into a separate post-build action
inside jenkins, one that happens outside e.g. the docker image.  This would
mean we mount some "output" directory from the build slave into the container
where the artifacts are stored to persist beyond the "--rm" docker container.

>From there, we should be able to scp/rsync/... the artefact to the [ftp] server,
using e.g. SSH agent forrwarding with credetials provided by the server.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list