Yes, your general assessment is correct. You can, but do NOT necessarily need to use the jenkins DSL plugin to generate jobs since JJB has it's own DSL. Not sure if 'out-of-band' mean separate executable, separate jenkins job definitions, or in repo vs out of repo. JJB does have an executable that you run and it does read it's own yaml based definition files. The JJB definition files will generate the actual jenkins xml files that define the jenkins job and deploy those to the jenkins master. JJB provides a path[1] option so the yml definitions can live anywhere, in your project's repo or out of it. I think the quick start guide[2] provides some good example of how all this works.
JJB deploys all jobs onto jenkins which if you have lots and lots of jobs can make the jenkins UI not real user friendly. JJB does not help with organizing jobs into views or folders at this time. Again, those features are in development right now so hopefully with a little more contribution those will land sometime in the near future :) [1] http://docs.openstack.org/infra/jenkins-job-builder/execution.html#passing-multiple-paths [2] http://docs.openstack.org/infra/jenkins-job-builder/quick-start.html On Monday, August 31, 2015 at 9:43:31 AM UTC-7, milki milk wrote: > > > On Monday, August 31, 2015 at 9:11:54 AM UTC-7, Khai Do wrote: >> >> Answers to your questions.. >> >> >>> When a repo needs testing, does it always go through the job generator >>> before going through the generated jobs every single time? >>> >> >> You can set it up to update jobs only when there are changes to the JJB >> definition files. For example we use puppet to monitor changes to the JJB >> definition files then have puppet run JJB to regenerate the jobs. JJB also >> has a local cache of existing jobs so the updates are idempotent. >> > > Ah. So this is how I'm understanding this then: > > * all jobs are generated out-of-band via jenkins-job-builder (presumably > via > http://docs.openstack.org/infra/jenkins-job-builder/builders.html#builders.dsl > ) > * each individual repo's jenkins.yml file are referenced by the DSL for > configured values. > > Going off of the summary of the article, it states: "developers to easily > create and configure the jobs for their repositories, without the usual > copy/paste problems, while still allowing" > > If the jenkins.yml is only for configured values for already generated > jobs, then how do developers "create" jobs for their repositories. It seems > like they would need to work with the JJB definition files which is > out-of-band of the repo. > > In the case that jobs are shared, then developers can configure their repo > for those shared and already created jobs. But, if a developer wants to > have a convenient UI view of their project jobs, it would be difficult to > isolate the relevant job history from shared jobs (e.g. shared job0 #4564 > triggered shared job1 #545212 triggered shared job2 #421). I believe that > view support becomes necessary in this case. > > How do you help developers view their relevant jobs? > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cd91aa94-5e8c-4e33-ae1d-7cf044420b52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
