On Monday, August 31, 2015 at 1:25:41 PM UTC-7, Guenther, Marc(AWF) wrote: > > Hi all, > > I think there has been a little bit of confusion here. > > 1. As described in my blog article, we are using Job-DSL-Plugin, not > Jenkins Job Builder (JJB). Both try to solve similar problems > (automatically generate jobs based on external descriptions) but there are > two very important differences: > - JJB is an external process communicating with Jenkins via REST-API, > whereas Job-DSL-Plugin runs inside of Jenkins itself. > - Job-DSL-Plugin uses Groovy DSL to describe their jobs, whereas JJB uses > plain Yaml files. The huge advantage of having a complete programming > language instead of just some templating engine was the main point of my > last blog. > > 2. The 'jenkins.yml' files I describe in the blog are purely our own > convention. Neither Jenkins Job Builder nor Job-DSL-Plugin use anything > like that. In particular, they have nothing to do with JJB's yaml files. > They also do not describe complete job definitions, but only choose and > configure existing definitions (what I wrongly called template). > > Those confusions being hopefully resolved, I would like to answer your > questions. >
Oh. So Khai Do isn't responding as someone who knows how Ebay's workflow works. Yes, this was the disconnect I was feeling because there was no mention of JJB, only a "job generator." Thanks for clearing that up. > On 28 Aug 2015, at 18:18, milki milk <nites...@gmail.com <javascript:>> > wrote: > > > Now this is more interesting. Using the .jenkins.yml file from the > repository to inform the job generator what jobs to create is similar to > travis. > > Yes, exactly. Only in this case it is more flexible, as the job definition > you choose through the 'jenkins.yml' file has the full power of > Job-DSL-Plugin available, which means it can do everything you can possibly > do in Jenkins. Travis afaik is not that flexible in what the jobs can do > (on purpose, at least that's what I understood from my last chat with one > of their developers). > > > Of course, the details are in the implementation in the next post. > > Oh, yes, reminds me that I still have to write that ;) > Yes! Very interested. JJB is limited by Jenkins and its plugins and the fact that is is essentially just POSTing XML to configuration pages. > > > I'm curious. > > > > When a repo needs testing, does it always go through the job generator > before going through the generated jobs every single time? > > I'm not sure what you mean by "when a repo needs testing". So when there > has been a commit in the repo, which changes the 'jenkins.yml' file, and > that commit gets pushed, then that change will be applied to the existing > jobs before they run. So technically, yes, every push goes through the job > generator, but it very quickly figures out when there is no change and will > run the real job(s). > Yup that answers my question. My "testing", I meant the project repo triggers a Jenkins job. Since the jenkins.yml file configures a job, are all project initial jobs essentially the same - read the yml, configure the jobs, run the jobs? > > Can you create nice views, folders, pipeline views as well? > > Yes, all of them. We heavily use Views and Folders, as each repository > gets it's own Folder in Jenkins, and inside there are Views for branches > and forks, for example. We also generate Delivery Pipeline Views. > This sounds great for users! So, while you have a handle on job management, do you find yourself with any performance issues for creating/deleting jobs? Additionally, do you see performance issues when all the jobs? I find that jenkins slows down with lots of jobs because it likes to parse job history and artifacts all the time and stuff everything into memory. How do you deal with the job history? When a job is deleted, all history is loss and links go stale. Do you archive history? -- 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/9ad5c99e-815c-4e69-91ff-f21e4830e945%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
