On 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