From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Sony.onmicrosoft.com; s=selector1-Sony-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pha1G/6ITIpgTp/brtbwONANJIFt3I4F/iG1Ox38vi8=; b=HeVIyLf3wX2wbNfM3lCNxiilXuhZVfzNzipSBEUeIsjjmVRY03n8S6D0vLepRVVwGTbgdfdOQ6lBFsSUm38k2w6LGAXhFmZlcScbr33opcZnS9+xSHxQGVi9SKGb9VbnT2dNgZ9aWC2qv7Wt8yyszNVCdB13sHYQEgAWoqOSUZA= From: "Bird, Timothy" Date: Thu, 2 Feb 2017 01:25:37 +0000 Message-ID: References: <000d01d26ba1$94c8a5d0$be59f170$@toshiba.co.jp> <003001d27b65$2d0c2650$872472f0$@toshiba.co.jp> <2089327.AE25eAEzJN@elrond> In-Reply-To: <2089327.AE25eAEzJN@elrond> Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fuego] Fuego's version up and other changes List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Jan-Simon_M=F6ller?= , "fuego@lists.linuxfoundation.org" > -----Original Message----- > From: Jan-Simon M=F6ller on Tuesday, January 31, 2017 12:55 PM >... > * A extension to this approach IMHO would be the use of jenkins-job- > builder. >=20 > 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. >=20 > Let me illustrate this with a jump-start example: > >=20 > Installation of jjb (in fuego container):=20 > $ cd ~/ > $ sudo apt-get install python-pip > $ sudo pip install jenkins-job-builder > # should be 1.6.x >=20 > $ cat < jjb-conf.ini > [job_builder] > ignore_cache=3DTrue > keep_descriptions=3DFalse > include_path=3D.:scripts:~/git/ > recursive=3DTrue > [jenkins] > user=3DAnonymous > password=3D > url=3Dhttps://localhost/ > ##### This is deprecated, use job_builder section instead > #ignore_cache=3DTrue > query_plugins_info=3DFalse > EOF >=20 > $ mkdir jjb > $ cd jjb/ > $ mkdir testjob > $ cat < testjob/testjob.yaml > - project: > name: fuego-tests-smoke > machine: > - raspberrypi3 > testname: > - > - > - > - > - > jobs: > - {machine}.smoke.batch > - {machine}.smoke.{testname} >=20 > - job-template: > name: '{machine}.smoke.batch' > project-type: freestyle > concurrent: false > node: master >=20 > builders: > - orchestrator-script ON > - trigger '{machine}.smoke.*' BLOCKING > - orchestrator-script OFF ALWAYS >=20 > - 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