On Tue, Mar 15, 2016 at 08:37:11AM +0000, Dominic Cleal wrote: > On 15/03/16 08:06, Niels de Vos wrote: > > Hi, > > > > I would like to run a Jenkins job on a regular schedule, and this job > > should run with different CentOS and Gluster versions. It is easy to > > write the job and pass the different environment. This works fine for > > manual execution with the Jenkins web interface > > > > Now, is there a trick or job-type in Jenkins that I can use to setup a > > schedule *and* pass different environment parameters for different > > times? > > > > The workaround would be to create multiple Jenkins jobs with different > > default parameters... But I do not think that is a very elegant > > solution. > > Similarly to that, the way I usually do this is to create multiple > Jenkins jobs that call the first job with different sets of parameters, > using the original as a shared utility job. > > As the main build step, use "Trigger/call builds on other projects", > enter the project name and then click "Add parameters", "Predefined > parameters" to enter a key=value list of parameters to pass through. > You can then add your notifications to this top-level task instead of > the inner one. > > The downside is that it takes up an additional slave slot with the > top-level job that's just waiting for another job to complete. It also > requires you to click through an additional page to view the results of > the inner job. Nice, this looks pretty easy to setup. I'll try that first. > A second way of doing it is to create a matrix job (you can't change an > existing job) and add the different parameters values as an axis on the > matrix. This works well when testing different combinations, e.g. > software versions, database types. The job would run all of the > combinations either in parallel or sequentially depending on > configuration, not at different times of the day. This might be what I want, but it looks more complex to configure. I might change to this when I understand better how it works. > Lastly, the duplication of jobs is much easier to manage if you use > Jenkins Job Builder (JJB) or similar to generate your jobs from config > files. You can define the job as a template in a single file and > although Jenkins will contain multiple jobs all with identical > configuration steps, there's no extra work to keep them in sync when > using the tool to manage the job configurations. Yeah, I thought about that too. But I have no experience with JBB and it would create many different, but almost the same Jenkins jobs. Even if the jobs are managed outside of the Jenkins webui, it feels a little like polluting the environment. Thanks for the suggestions! Niels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.centos.org/pipermail/ci-users/attachments/20160315/d5c37196/attachment-0002.sig>