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.deHi Blobb, I'd like to probe your opinion on a discussion we had today about our jenkins. So far our setup was manual, and we would like to (somewhat) automate the process of providing build dependencies on slaves. One solution that was discussed longer than others would be to use docker. Each of our repositories that need a build would have their own docker file, containing the complete setup of dependencies. The idea is that anyone can easily setup an identical build on any new jenkins build slave or even at home; no complex config of the jenkins build slave is needed. The point being, if we adopt docker in such a way, it would be logical to make use of the docker cache to save unnecessary rebuilds. It is a generic solution instead our artifact store. I feel a bit bad for accepting your contributions, doing review and keeping you busy, just to then talk about docker to solve the problem instead; I appreciate your presence and would like to keep you involved. Interestingly enough, we are experimenting with the artifact store on that one build job that has already been using docker for quite some time... (It was for the separate network space, not really for artifacts.) In any case, I would like to include you in the discussion, and maybe you would also like to be involved in maturing the idea? Until now it is still wild and no-one has taken actual steps. An example to follow would be laforge's recently added https://git.osmocom.org/docker-playground/tree/ One interesting bit is that it has a method to check whether a given git branch has changed, and rebuilds the docker image only if it has: https://git.osmocom.org/docker-playground/tree/osmo-ggsn-master/Dockerfile#n20 ADD http://git.osmocom.org/openggsn/patch/?h=laforge/osmo-ggsn /tmp/commit This line fetches the given URL (in this case the latest patch on that branch) and considers the docker image as unchanged if that URL shows the same as last time. As soon as a new patch shows, things are rebuilt. In this sense we could have docker images cascading on top of each other, adding individual dependencies and reusing identical states auto-detected by docker. All build steps would be in the Dockerfile. For builds that aren't used by other builds (like the "final" programs, osmo-msc, osmo-sgsn, osmo-bsc,...) we don't need to store the result, so don't need to include the program's build in the Dockerfile: on a docker image with all dependencies, run the final build step by invoking 'docker run', like we currently do for the OpenBSC-gerrit job, and then just discard the changes. Remotely related: we have the osmo-gsm-tester that is running binaries produced by jenkins to do automated tests on real GSM hardware. Currently we compile and tar the binaries, copy them over, extract, set LD_LIBRARY_PATH and run: a bit tedious and problematic e.g. for mismatching debian versions. This could be simplified by docker by guaranteeing a fixed operating system around the binary, actually using hub.docker.com (or maybe one day a private docker hub) instead of copying over binary tars manually, sharing across any number of build slaves, and with the added bonus of having the resulting binaries run in a separate network space. As I said, on the one hand I appreciate our work on the artifact store, on the other hand the docker way undeniably makes for a good overall solution to simplify things in general, with artifact re-use coming "for free"... One advantage of the artifact store though is that the artifacts we manage are not entire debian installations but just a few libs and executables in a tiny tar. What is your opinion? ~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/20170905/c6e37562/attachment.bin>