4 Mar
2017
4 Mar
'17
4:24 p.m.
On Sat, Mar 04, 2017 at 08:57:08AM +0100, Holger Freyther wrote:
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:
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. :) 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