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.deToday I noticed that osmo-msc-master was being built several times in a row and I found there are multiple redundant ricocheting downstream builds of the same original upstream build timer. All of: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/ show: Started by upstream project master-libosmocore build number 1624 And then there are: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/ showing: Started by upstream project master-libosmo-abis build number 2611 So there are two timers launching master-libosmocore and launching master-libosmo-abis, and each of these cause multiple downstream build triggers of osmo-msc. Then there is also the osmo-msc timer, independently launching more nightly master-osmo-msc builds. It is not necessary to depend these builds on each other, because none of them depends on artifacts built in another job, each of them in turn builds the entire chain of libosmocore up to that build's target project. Upon a libosmocore *code change*, it makes sense to trigger downstream builds, but not when caused by a timer or for other jenkins trigger or user reasons. I vaguely remember discussing this before, but now I realize we could solve this and have less redundant builds: Do not configure libosmocore to trigger downstream builds of master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on the master-libosmo-abis build job config, making a patch-merge to the gerrit libosmocore.git cause a master-libosmo-abis build. At that point, jenkins timers no longer cause downstream builds, but merges to master on upstream git repositories do still cause builds. (maybe there is also a normal git SCM way that doesn't require gerrit.osmocom.org?) For projects like osmo-msc, we would add multiple projects as upstream git repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh, osmo-mgw, ... Basically all of the projects with more than one dependency get retriggered redundantly every night, some doing their entire build matrix over several times for no good reason. I'm not sure that it's really worth the effort, but I thought I'd mention it since seeing so many redundant builds on various osmo source trees at night seems avoidable stupidity. Should someone spend cycles to implement this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200812/b77f73a6/attachment.bin>