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 <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
