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. On 28 Aug 2015, at 18:18, milki milk <nitesha...@gmail.com> 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 ;) > 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). > Does the job generator clean up any jobs that are no longer used when the > yaml file changes? Yes, that's a feature of the Job-DSL-Plugin itself, it keeps track what it generated on the last run, and deletes everything that it didn't generate this time. > Are the jobs generated unique per repository or shared? Unique. Every repository has it's own job(s). Or, more clearly, every job always belongs to one and only one repository. You can trigger jobs of other repositories (aka upstream/downstream jobs), of course. (I wasn't really aware that you could have one job listen on multiple repositories in Jenkins, and if so, why one would do such a thing). And regarding Khai Do's reply who answered "Shared", I guess what he was referring to was "job definitions". These are indeed shared, only the jobs generated from them are unique for each repo. > 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. On Monday, August 31, 2015 at 10:50:59 AM UTC-7, milki milk wrote: > Another thing that plagues my use of JJB is the fact that Security > credentials, like those uses in the git scm configuration, must be hardcoded > the Credential ID string. This string is unique to each Jenkins master > instance though which means jobs with these strings must be uniquely defined > per instance. Do you use Credentials in your JJB definition files? If so, how > do you manage the hardcoded strings? Recent version 1.21 of Credentials Plugin allows to specify meaningful IDs for your credentials, so you can reuse them over several Jenkins masters, which is veeeeery convenient. You could also use EnvInject-Plugin to inject credentials as build variables, but Credentials Plugin is more secure. Hope this makes sense, Marc -- ** Marc Guenther ** mguent...@team.mobile.de ** Engineering Support ** mobile.de ** -- 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/6255C4E2-D402-44DF-B5C3-6AB4DEB9F8AC%40ebay.com. For more options, visit https://groups.google.com/d/optout.
