[Fuego] Parameter passing to tests

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Fri Jun 2 15:43:18 UTC 2017

> -----Original Message-----
> From: Rafael Gago Castano [mailto:RGC at hms.se]
> Sent: Saturday, June 03, 2017 12:00 AM
> To: Daniel Sangorrin; fuego at lists.linuxfoundation.org
> Subject: Re: [Fuego] Parameter passing to tests
> > Yes, a script calling "ftc add-jobs" with the parameters is another perfectly valid option.
> Here I suspect that you may be missing how jenkins parametrized builds
> work.
> Those are parameters managed by jenkins that are only required and modifiable at
> build (test-run) time both from the web and native jenkins CLI interface. You
> seem to imply as if the had to be defined add job creation time.
> You can create some parameters in a dummy fuego project:
> https://st-g.de/2016/12/parametrized-jenkins-pipelines
> You will see that each string parameter has a name, default value and
> description. These parameters are made environment variables automatically by
> Jenkins and you can pass them natively at build time. So the only thing needed
> at job-creation time is to define the Key name, the default value (optional) and
> the description (optional).
> So on the jenkins CLI you run:
> java -jar /opt/jenkins/jenkins-cli.jar -s http://localhost:8080/fuego build <test-name> -p PARAM1="hello param 1" PARAM2="hello
> param2"
> And if you build through the web interface jenkins promts you for the actual
> values before building.
> Note how on the JSON spec I created there is a 1:1 mapping with the jenkins
> string parameter (name + default value + description). These are added to the
> project XML as I showed in some previous mail.

Thanks for your explanation. Actually, Fuego used to work with parameterized
builds (drop down choice menus) until I completely removed them ;)

The reason I removed them was because of this part that you mention
 "interface jenkins promts you for the actual values before building". 
That is very very annoying, at least for me.

Fuego now has a different approach. You decide the parameters at job creation (i.e. not each time you do a build) and
then you just forget about it. Your jobs will be run _automatically_
without any interaction needed whenever you want them to be triggered (e.g.: every day at 0:00). 

Having said that, if there is a way to use _automatic_ parameterized builds I would like to know because
that could solve the problem for both of us.

> > My only concern then is how do you avoid Jenkins job collision?
> > For example, if you create 2 jobs with the same spec but you override the parameters.
> I wasn't aware that a Jenkins job/project can run simultaneously on different
> build nodes. Jenkins, when used as a build server should be able to build two
> branches of the same project simultaneosly if configured to (I guess). Be sure
> to try a parametrized build with different parameters. This may be a jenkins
> config issue only.

What I meant was a collision in "job/project names" because they would have the same
spec under the current Fuego. Also Fuego is able to compare test results for different specs.


More information about the Fuego mailing list