Aaron, Thanks for the reply. What happens when I set the quiet period to 8 hours is that every build of Project A resets that timer and it's very likely that Project B will never build.
To further clarify I've used the example from my previous post and listed what happens and what I desire to happen. 9:00 Project A build #1 completes and Project B build #1 gets queued (wait time of 8 hours) 9:48 Project A build #2 completes and Project B resets its wait timer (I want nothing to happen with Project B) 10:36 Project A build #3 completes and Project B resets its wait timer (I want nothing to happen with Project B) 1:05 Project A build #4 completes and Project B resets its wait timer (I want nothing to happen with Project B) 5:00 (Nothing happens but I want Project B build #1 to start since the original queue happened 8 hours ago) 5:01 Project A build #5 completes and Project B resets its wait timer (I want nothing to happen with Project B) As you can see, Project B will never build as long as Project A builds in that 8 hour timeframe. This is related to my separate post about a max value for quiet periods. If I could configure Project B with an 8 hour wait time but also give it a max value of 1 wait time before it builds then it should work. -Lewis On Thursday, June 14, 2012 5:00:44 PM UTC-7, AaronTC wrote: > > If I understand your question correctly, it seems like you could just add > an 8 hour quiet period on Project B, which means it will build at most > every 8 hours. > > -Aaron > > On Thu, Jun 14, 2012 at 1:21 PM, Mandeville, Rob <[email protected]>wrote: > >> If I was confronted with this, I might just put project B on a schedule >> to run three times a day. For extra credit, I’d check the SCM to see if >> anything has changed since the previous build and skip the build if that’s >> the case.**** >> >> ** ** >> >> --Rob**** >> >> ** ** >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Lewis >> *Sent:* Thursday, June 14, 2012 4:11 PM >> *To:* [email protected] >> *Subject:* Re: Building**** >> >> ** ** >> >> Rob, >> I have two different types of builds. One uses some prebuilt packages >> ("Project A") and the other builds everything including those packages that >> are prebuilt ("Project B"). Since Project B takes more time to build I >> don't want to run it very often. >> >> I have Project A polling the SCM and building as it should. I would like >> Project B to get queued when Project A builds and wait 8 hours for any >> other changes that might take place. I don't want to run this big build for >> every checkin. So what I want is for the first build of Project A to queue >> a build of Project B and I don't want it to queue again until Project B >> starts running. >> >> So it would work like this: >> >> 9:00 Project A build #1 completes and Project B build #1 gets queued >> (wait time of 8 hours) >> 9:48 Project A build #2 completes (nothing happens with Project B) >> 10:36 Project A build #3 completes (nothing happens with Project B) >> 1:05 Project A build #4 completes (nothing happens with Project B) >> 5:00 Project B build #1 starts >> 5:01 Project A build #5 completes and Project B build #2 gets queued >> >> Yes, this question is somewhat related to my other question in that >> Project B will never build if I configure it to be a post-build action of >> Project A with a quiet period of 8 hours. >> >> I believe the other question applies to are more common scenario though. >> I don't want my builds to be queued infinitely. >> >> Thanks for your help, >> Lewis >> >> On Thursday, June 14, 2012 12:01:50 PM UTC-7, Lewis wrote:**** >> >> I would like to have Project A trigger a build of Project B with a very >> large wait time (about 8 hours). >> I do not want the project to reset it's wait time if Project A builds. >> >> Instead of trying to queue the project again and resetting the wait time >> I would like Jenkins to realize >> that the project is already in the queue and ignore it. >> >> Is there a known way to do this? >> >> -Lewis**** >> The information in this message is for the intended recipient(s) only >> and may be the proprietary and/or confidential property of Litle & Co., >> LLC, and thus protected from disclosure. If you are not the intended >> recipient(s), or an employee or agent responsible for delivering this >> message to the intended recipient, you are hereby notified that any use, >> dissemination, distribution or copying of this communication is prohibited. >> If you have received this communication in error, please notify Litle & Co. >> immediately by replying to this message and then promptly deleting it and >> your reply permanently from your computer. >> > > > > -- > Aaron Ten Clay > http://www.aarontc.com/ > >
