> 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%[email protected]');>. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/547DDA43.5040808%40gmail.com. For more options, visit https://groups.google.com/d/optout.
