On Tuesday, December 2, 2014, Kenneth Baltrinic <[email protected]> wrote:
> Gentlemen, > > Thank you all for your responses. Here are my thoughts on the combination > of replies. > > The literate build plugin is closest in concept to what we are looking for > but it seems too limited in capabilities for what we need. If it could > handle a full DSL such as the JobDSL, BuildFlow and Workflow plugins > provide, > Well I know that workflow will be getting some of the branch-api support, so watch that space > it would exactly we need. Its focus however seems to be as a replacement > for simple freestyle builds which basically run shell scripts. We have > fairly complex builds that use a number of Jenkins plugins to integrate > with various build tools, etc. > Ha! You have not looked closely enough... You just need to do the right transformation from the literate description > We would not want to lose that functionality. > Keep in mind that all Publishers are supported out of the box also > Also it does not appear, based on the state of the code and todo list, to > be production ready. > If you don't need pull request support, it's nearly there. Pull request support would open up the possibility of drive-by hacking. I do not view the plugin as 1.0 ready until people can have pull request support without the risk of drive-by hacking > > As for Patricks approach of hiding the extra jobs, I am not sure I can > make that fly here but its still on our list of possible solutions if we > must. Our concern is the sheer number of jobs, each getting its own folder > structure on our slave nodes and incurring other overhead. Does anyone > have any practical advice about how many jobs one can reasonably pile onto > a single Jenkins installation (one master, about a dozen slaves in our > current case). Are there any practical limits, best practices around this? > > As for the travis.yml parser, I couldn't find anything on google about a > travis.yml parser for Jenkins. > It's in literate-api Amadeus have a more full implementation but I cannot recall if they published it yet > However while conceptually what travis does and what we want are the > same, (build definition incorporated into the source repo) the underlying > build capabilities we need to support are very different from what travis > supports. Assuming it is attempting to provide a travis-like feature set, > it would be very much in the same position as the literate build. > > Any further thoughts? > You can provide your own literate format and add your own parser that builds the job the way you want and presto you are standing on the shoulder of literate ;-) > > --Ken > > On Tuesday, December 2, 2014 10:27:18 AM UTC-5, Patrick van Dissel wrote: >> >> > We have a working prototype right now that manages this with two >> separate jobs. One to watch the SMC and rebuild the downstream job >> based on the build.yml and a separate downstream job that kicks off when >> the first completes successfully. (Given the first might fail if the >> yaml files is invalid, etc.) The problem with this approach is that we >> have hundreds of builds already, doubling the number of builds as this >> approach will do, is not considered acceptable. >> >> This is exactly what we have also, but instead of a custom yaml file we >> use the Jenkins Job DSL plugin: >> - https://github.com/jenkinsci/job-dsl-plugin >> >> About the amount of jobs, we think it's not a problem :) You can "hide" >> those additional jobs in different views if wanted. It's just one >> additional job per project, and each project already has atleast 6 jobs >> anyway. >> >> We have a seperate service running, which injects the initial "Seed" job >> (currently trigger by a state change of a story in Jira). This seed job >> runs the jobDsl file of that project to generate the rest of the jobs of >> that project. >> With this we've have complete story based development (aka feature >> branches). So for each story we create the whole pipeline of that >> application. Other services take care of setting up the story-based >> infrastructure. >> >> For us, the JobDSL is a perfect fit. It provides the flexibility to the >> teams to configure their own application pipelines which go beyond the >> basic CI setups that TravisCI and lookalikes provide. >> >> /Patrick >> >> >> On 12/02/2014 03:27 PM, Stephen Connolly wrote: >> > Your effort might be best placed helping us beef up the (stub) >> > travis.yaml parser to one that is more useable. >> > >> > On Tuesday, December 2, 2014, James Nord <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi >> > >> > What you are attempting sounds like the litterate job type - have >> > you looked at this plugin? >> > >> > /James >> > >> > >> > >> > On 2 December 2014 13:31:19 GMT+00:00, Kenneth Baltrinic >> > <[email protected] >> > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> > >> > I have been tasked to look at how we can set up a self service >> > CI system for a large development shop, much along the lines of >> > how travis CI works. There are big differences between what we >> > need and what Travis CI provides but the basic idea of having a >> > yaml file within the repository itself specify what the build >> > server should do is what we are aiming for. >> > >> > Jenkins-Job-Builder from OpenStack seems to provide what we >> need >> > from the standpoint of being able to take yaml files and create >> > Jenkins jobs from them. The part that I am seeking advice on >> is >> > how to make this work from within a job, specifically we are >> > looking for a workflow something like this: >> > >> > * Given a job that is configured with an SCM Poll to poll a >> > given git repository. >> > * When that poll triggers. >> > o Get the latest source >> > o Evaluate the build.yml file to create the rest of the >> > jenkins job to executed >> > o Execute the rest of the build job. >> > >> > We have a working prototype right now that manages this with >> two >> > separate jobs. One to watch the SMC and rebuild the downstream >> > job based on the build.yml and a separate downstream job that >> > kicks off when the first completes successfully. (Given the >> > first might fail if the yaml files is invalid, etc.) The >> > problem with this approach is that we have hundreds of builds >> > already, doubling the number of builds as this approach will >> do, >> > is not considered acceptable. >> > >> > Any advice or thoughts on what might be the best approach to >> > doing this will be greatly appreciated. >> > >> > --Ken >> > >> > >> > -- >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> > >> > -- >> > 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 [email protected] >> > <javascript:_e(%7B%7D,'cvml','jenkinsci-users%2Bunsubscribe@ >> googlegroups.com');>. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/jenkinsci-users/ >> 49B39C84-10A8-4079-94B3-44C346EB45B6%40teilo.net >> > <https://groups.google.com/d/msgid/jenkinsci-users/ >> 49B39C84-10A8-4079-94B3-44C346EB45B6%40teilo.net?utm_ >> medium=email&utm_source=footer>. >> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > >> > -- >> > Sent from my phone >> > >> > -- >> > 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 [email protected] >> > <mailto:[email protected]>. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/jenkinsci-users/CA% >> 2BnPnMwUjERstjqpbUjjEQdZJLHEPPP1oFJb2a%3D_Fq%2BO8Fy4XQ%40mail.gmail.com >> > <https://groups.google.com/d/msgid/jenkinsci-users/CA% >> 2BnPnMwUjERstjqpbUjjEQdZJLHEPPP1oFJb2a%3D_Fq%2BO8Fy4XQ% >> 40mail.gmail.com?utm_medium=email&utm_source=footer>. >> > For more options, visit https://groups.google.com/d/optout. >> > -- > 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 [email protected] > <javascript:_e(%7B%7D,'cvml','jenkinsci-users%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/e8dffb79-0fb8-4a3c-af54-c2ed5ccf94ef%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/e8dffb79-0fb8-4a3c-af54-c2ed5ccf94ef%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwGUDGxOLjSte3hL_euU2Uk_jMh9T_hzyw7TxRSOqn1RA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
