[Fuego] Fuego's version up and other changes

Bird, Timothy Tim.Bird at sony.com
Thu Feb 2 01:25:37 UTC 2017



> -----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.
 -- Tim



More information about the Fuego mailing list