[Fuego] Fuego's version up and other changes

[Daniel Sangorrin]

> -----Original Message-----
> From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> Sent: Thursday, February 02, 2017 10:26 AM
> To: Jan-Simon Möller; fuego at lists.linuxfoundation.org
> Cc: Daniel Sangorrin
> Subject: RE: [Fuego] Fuego's version up and other changes
> 
> 
> 
> > -----Original Message-----
> > From: Jan-Simon Möller on Tuesday, January 31, 2017 12:55 PM
> >...
> > * A extension to this approach IMHO would be the use of jenkins-job-
> > builder.
> >
> > The beauty of this is that we do not have to deal with the xml ourselves.
> > Instead we define yaml files and let jjb create the necessary xml.
> > Another plus is that such an approach would also allow ppl to add
> > the testcases to an *existing* jenkins using the jjb templates.
> >
> > Let me illustrate this with a jump-start example:
> >
> >
> > Installation of jjb (in fuego container):
> > $ cd ~/
> > $ sudo apt-get install python-pip
> > $ sudo pip install jenkins-job-builder
> > # should be 1.6.x
> >
> > $ cat <<EOF > jjb-conf.ini
> > [job_builder]
> > ignore_cache=True
> > keep_descriptions=False
> > include_path=.:scripts:~/git/
> > recursive=True
> > [jenkins]
> > user=Anonymous
> > password=
> > url=https://localhost/
> > ##### This is deprecated, use job_builder section instead
> > #ignore_cache=True
> > query_plugins_info=False
> > EOF
> >
> > $ mkdir jjb
> > $ cd jjb/
> > $ mkdir testjob
> > $ cat <<EOF > testjob/testjob.yaml
> > - project:
> > name: fuego-tests-smoke
> > machine:
> > - raspberrypi3
> > testname:
> > -
> > -
> > -
> > -
> > -
> > jobs:
> > - {machine}.smoke.batch
> > - {machine}.smoke.{testname}
> >
> > - job-template:
> > name: '{machine}.smoke.batch'
> > project-type: freestyle
> > concurrent: false
> > node: master
> >
> > builders:
> > - orchestrator-script ON
> > - trigger '{machine}.smoke.*' BLOCKING
> > - orchestrator-script OFF ALWAYS
> >
> > - job-template:
> > name: '{machine}.smoke.{testname}
> > project-type: freestyle
> > concurrent: false
> > node: {machine}
> 
> I like the idea of using a tool maintained by others
> to handle the interaction with Jenkins.  This will
> insulate us from additional Jenkins changes.  I do
> worry a bit, however, about exposing Fuego users
> to a whole bunch of extraneous Jenkins or jjb
> info that they don't need just to install and run tests
> on their boards.
> 
> If the complexity of the above can be hidden from
> the 'casual' user, who has a board, and just wants to
> run an existing test on it, then that would be good.
> For me, this includes the whole issue of plans and
> specs as well.  I'd like to make awareness of those
> optional for Fuego users who don't need them.
> 
> Daniel's scripts take a minimum of arguments, and
> do a pretty good job in this regards.  If they can
> use jjb behind the scenes, making it so that end users
> don't have to fiddle with YAML files full of weird,
> Jenkins parameters, that would be good, IMHO.

Yeah, I agree with that. The simpler for the users the better.
Also for the poor developers.

Daniel