Hi, Baptiste. Not sure what you mean if the workspace gets wiped out, it always does, I have jenkins clean the workspace before each job. I'll have to look into his pipeline plugin, thanks for this pointer.
Rick On Friday, May 13, 2016 at 3:56:18 PM UTC-4, Baptiste Mathus wrote: > > How do you handle the fact that even with Freestyle job, if the workspace > gets wiped out or has an issue, you'll get a build even if the source > didn't change? Is that gonna be a big issue? > > This really sounds like a job for the pipeline plugin. Handling in your > case 12 different jobs and that kind of relationship should be simplifiable > with one central script to handle all that. > > One of the thing which makes me unsure on how to do it, is the fact you > may want to have some parts in parallel, but still limit the number of > those executions. Maybe an evolution to the parallel step, which could take > an additional `maxPoolSize` parameter or something. > > HTH > > 2016-05-09 21:53 GMT+02:00 Rick Patterson <[email protected] > <javascript:>>: > >> Hi. >> >> I have 10 related software components to build (jobs 1 through 10), which >> are somewhat independent of each other, and presently they each trigger >> individually on a source change, i.e. their builds only go if their source >> changes. We have the check for these components source changes staggered, >> according to a nightly schedule, a half hour hour apart, so that they do >> not all go off at once, in case they all did happen to have a source >> change, as I do not wish to hog the build machine from other jobs. The >> problem is I do not know whether one or more of these jobs actually build >> upon a source change, I have to assume at least one always builds, and so I >> am always running an 11th job (test), and a 12th job (install kit), >> according to a timed schedule, which may not need to be actually run if >> nothing actually changed. >> >> I do not see how to do this in Jenkins. if I have job 1 configured to >> start job 2 as a post-build step ("Build other projects"), then it seems to >> always start it, whether the source has changed or not. So, this does not >> seem to be a workable method to see if the 10 jobs have a source change. >> >> It'd be nice to check through all 10 jobs, and only build each one >> sequentially, if they have do have a source change, instead of scheduling >> them 1/2 hour apart. Then, if any one or more did actually build, then do >> the test, and if the test works, then do the kit. >> >> Summary: first 10 jobs need to be checked for source changes, and they >> only build individually if they have a source change. >> if any of the first 10 jobs build okay, (regardless of any other job's >> failures), only then does the 11th job needs to start. So, all of the >> first 10 jobs need to be checked , and one or more actually build, before >> possibly doing the 11th job. >> If 11th job is okay, then 12 the job goes. This last part I can do with >> existing "Build other projects" or "Trigger Parameterized Builds plugin" >> mechanisms. >> >> -- >> 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:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/36e8340d-dc79-4f84-9e78-7ccc64a6e105%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/36e8340d-dc79-4f84-9e78-7ccc64a6e105%40googlegroups.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/ee2fd93b-c2eb-447d-808c-5a48ff49435a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
