jenkins slave setup and artifact re-use

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.de
Thu Sep 7 04:53:28 UTC 2017


The one thing I would have done differently: 

Why not have a series of Dockerfiles for each git, building onto the Dockerfile
of its "next" dependency?

By having all gits in one joint image we "smudge" the build environment, or
need to worry about cleaning things up first.

You said you would prefer having not so many images around, but what is the
reason? I thought the images were incremental, and if one references the
previous, there is only a small difference taking up space for it?

I'm thinking of a cascade like this:

 debian
  \
   libosmocore
   |
   libosmo-abis
   |
   +---------------- osmo-hlr
   |
   libosmo-netif
   |
   libosmo-sccp
   |
   osmo-iuh
   |
   +---------------- osmo-ggsn
   |                 |
   |                 osmo-sgsn
   |
   osmo-mgw
   |
   libsmpp34
   |
   +---------------- osmo-bsc
   +---------------- osmo-msc

It's a compromise of least dependencies and avoiding dupes, resulting in 13
different stages.

The libosmocore job would update the libosmocore image, the libosmo-abis job
builds on it to produce the libosmo-abis image, and so forth. The jenkins jobs
would naturally re-use the other jobs' results and be clean every time.

The downside is to have to run ~8 different images for a core network (e.g. on
the osmo-gsm-tester). But is docker managing it such that it doesn't take up 8
x the space and RAM, just one debian + 8 little increments?

On the osmo-gsm-tester we can then freely combine various versions of the
different core network components by simply running a different image per
binary. Would be great to not build separate tester images anymore.

Anyway, that was my first intuition. Maybe one joint image is more practical
after all, but harder for me to imagine ATM.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170907/1bc32867/attachment.bin>


More information about the OpenBSC mailing list