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.deOn Sat, Mar 04, 2017 at 08:57:08AM +0100, Holger Freyther wrote: > > About the distribution of scripts: the osmo-ci has common scripts, and each > > project's jenkins.sh has project-specific steps in it. Either we keep all > > The reason I moved the build instruction out of the Job into a file is to > have people easily rebuild/reproduce it. E.g. it helps with people that > either don't know make distcheck or can't copy the invocation from the log. > > I think if someone wants to reproduce the failure, it will be difficult for > that person to checkout the right repository with the build script. :) At the moment the jenkins.sh actually depends on osmo-ci scripts, so said someone would also need the right repository as well -- short of understanding what 'osmo-build-dep.sh libosmocore' means :P On Sat, Mar 04, 2017 at 10:43:27AM +0100, Harald Welte wrote: > what about git-subtree or git-submodule for osmo-ci? Probably a good idea. Though, submodules require manual steps to check out, right? So a README is needed anyway. With osmo-ci submoduled it's also a small step to actually move the various jenkins.sh into osmo-ci and be able to edit them centrally? :) anyway, not high up on the agenda. On Sat, Mar 04, 2017 at 08:57:08AM +0100, Holger Freyther wrote: > What I think should be avoided is to use Jenkins specific files. You might > need to install Java and tons of jars to locally drive your build. ;) [and] On Sat, Mar 04, 2017 at 10:43:27AM +0100, Harald Welte wrote: > I have a strong opinion against our developers having to learn a new > programming language just for continuous integration. That would be a > *very* high price to pay. Have all build steps in shell scripts that can run on their own, and accompany that with a jenkins specific file to drive the pipeline, which basically calls the shell scripts? On Sat, Mar 04, 2017 at 10:43:27AM +0100, Harald Welte wrote: > Also, in general I appreciate steps that improve productivity. But > please keep in mind that using new tools/toys just because they exist > and may be hyped is not a good reason. I'm not saying this is the case > here, but I'm saying we have to be careful. So, what would be the actual benefits? * complete job config in git? (to be confirmed) * faster because less things have to be rebuilt? (to be confirmed) * faster because easily parallelizable/easier integration with docker? (to be confirmed) If dr.blobb and/or Max could clarify these points that would be great (while I guess they will clarify in depth only after actual trials). First tests could run on a privately setup Jenkins ... dr.blobb? ~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/20170304/c3600cdf/attachment.bin>