jenkins matrix + --enable-iu

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

Max msuraev at sysmocom.de
Mon Jul 18 08:15:54 UTC 2016


Personally I don't mind waiting longer - it's background job which does
not prevent me from working on smth else while build happens.

On 07/13/2016 03:12 PM, Neels Hofmeyr wrote:
> Hi list,
>
> I've got a jenkins job ready that adds --enable-iu to the openbsc build matrix.
>
> I'd like to verify with you guys: so far we had a build matrix of 2 x 2, so
> openbsc and all its dependencies are built four times over (~22 min).
> Adding --enable-iu doubles this matrix to eight times.
>
> This means that any new commit would take about 55 min to verify with jenkins,
> even if it is just a comment tweak.
>
> I assume we want to bring this time down a bit?
>
> I'd have these suggestions:
>
> (1)
> Just add --enable-iu, let jenkins build for hours and proliferate global
> warming, and care about this once it actually bugs us.
>
> (2)
> Limit the build matrix: Only build --enable-iu once, e.g.  with --enable-smpp
> and --enable-mgcp-transcoding, not with all of the other combinations. (Would
> --disable-mgcp make more sense?)
>
> (3)
> Don't build all of the dependencies over and over. In pseudo sort of:
>
>   dep_hashes = ""
>   for dep in libosmo*:
>     dep_hashes += "," + dep.get_current_git_hash()
>     if dep.last_hashes == dep_hashes:
>       dep."make install"
>       continue
>     dep.wipe_out()
>     dep."autoreconf; configure; make check; make install"
>     cat dep_hashes > "${dep.dir}/last_hashes"
>
> That would shorten the build time substantially, and we could keep the build
> matrix fully featured without taking too much time.
>
> I've so far spent 5 minutes on implementing something like this and could
> polish that up, maybe using a global dependencies workspace somewhere else on
> the build slave so the separate matrix items benefit from each other.
>
> But do we like that?  I would consider re-using previous builds safe enough for
> our jenkins verifier, since all deps would be rebuilt even if only one dep's
> git hash changes; assuming that it *works*, of course. Do you guys agree?
>
>
> http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit-test/
> openbsc.git branches osmocom/jenkins-test and neels/speed_up_matrix_builds
>
> Thanks for your opinions!
>
> ~Neels
>

-- 
Max Suraev <msuraev at sysmocom.de> http://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 




More information about the OpenBSC mailing list