Hi Neels, 2018. dec. 6. dátummal, 13:38 időpontban Neels Hofmeyr <nhofmeyr(a)sysmocom.de> írta: I think Linux network namespaces would be a possible solution for this issue, if I understood correctly, but setting that up feels to me more complicated then using Docker. Just my 2cents. Cheers, Domi

Hi Holger and List, On Thu, Dec 06, 2018 at 04:26:47PM +0000, Holger Freyther wrote: 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]. 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. 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. using e.g. SSH agent forrwarding with credetials provided by the server. -- - 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)

On 12/7/18 11:58 AM, Oliver Smith wrote: One edge case: libosmocore gets compiled on FreeBSD_amd64. How would we handle that if we want to build everything with Docker? -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Hi Stephan, On Fri, Dec 07, 2018 at 05:18:22PM +0100, Stefan Sperling wrote: Indeed, this is true. We once had build testing for more projects on FreeBSD, but the amount of time fixing those issues was considerable, while at the time we did a quick poll and not a single FreeBSD user identified themselves at this mailing list. So the decision was clear, and we concluded, as you write: However, let me re-state that we are happy to merge any compatibility/portability related patches, should there be any developers/users on other platforms that contribute such changes. I just want to make clear that we're not ignorant of or somehow opposing other platforms. It's just that we focus our existing resources where we feel they are spent most effectively. 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)