jenkins build slaves: Rationale for some builds in docker vs. some not?

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

Holger Freyther holger at freyther.de
Tue Aug 29 23:12:06 UTC 2017


> On 27. Aug 2017, at 16:28, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 

Hey!


> Unfortunately, documenting the jenkins setup while tweaking it is time
> consuming and tends to become outdated quickly. I think documenting our entire
> setup is nontrivial. I did so for the osmo-gsm-tester jobs, which takes up a
> large part of the osmo-gsm-tester manual. We need to find a feasible balance of
> detail, which I guess should be rather coarse. Numerous documentation and wiki
> restructuring tasks for Osmocom components themselves are continuously pending
> and IMHO higher in priority.

Documentation is always prone to being outdated (leave alone some random notes
in a wiki...) and it takes a lot of effort to keep it updated. What I think works
is to automate as much as possible. This allows someone to _read_ the log and
try things.

In the sysmocom system-images I played with the XML "template" and the java
client to create/update jobs but Lynxis found that yaml DSL to describe jobs
more easily and I think we could explore that. We could have one repository
will all the jobs and run that to populate jenkins. E.g. this even enforces
standards like discarding old builds (we don't run on turing tape after all).


cheers
	holger


More information about the OpenBSC mailing list