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 <r.patterson...@gmail.com>:
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS40n1A58m-JEEncgZ-RKxEH9KaVd_UyXvEBMY%2BwTiZG%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
