Just FYI, from my experience 15 minutes is about the maximum that a commit-triggered build should run. Getting it below 7 minutes seemed to be a good goal, with slightly diminishing returns kicking in after that.
Skipping downloading (or at least grabbing from a local cache) should do a good job on helping the time. If it starts to go past 15 minutes for legitimate reasons, then that could be an opportunity to look into incremental builds. On 03/30/2015 02:06 PM, Keane, Erich wrote: > Thanks Bill! > > I highly doubt that even the 15mins is a reasonable amount of time, > since we are no longer downloading the Arduino the time should be much > less, but 90 should be a way more than required amount. > > Thanks! > -Erich > > On Mon, 2015-03-30 at 21:03 +0000, Dieter, William R wrote: >> It looks like there was another run away verification build today. I >> have had Linux Foundation install the Jenkins build timeout plug-in. >> >> >> >> As an initial starting point, I set the build timeout to 250% of the >> last 5 successful builds or 90 minutes (whichever comes first). >> Successful build times are currently averaging around 14 min 28 min. >> The longer jobs appear to have roughly 4x as many unit tests as the >> faster builds, according to the Jenkins ?Test Result Trend? graph. >> >> If anyone expects increase the build time by more than 2.5x the >> average or push it past 90 minutes, please let me know. >> >> >> >> Thanks, >> >> Bill. >> >> >> >> From: Dieter, William R >> Sent: Tuesday, March 24, 2015 11:17 AM >> To: Lankswert, Patrick; iotivity-dev at lists.iotivity.org >> Subject: RE: Jenkins build timeout plugin >> >> >> >> >> I believe it was Sam and Erich were working on building the unit tests >> and ran into the problem? >> >> >> >> Bill. >> >> >> >> From: Lankswert, Patrick >> Sent: Tuesday, March 24, 2015 11:00 AM >> To: Dieter, William R; iotivity-dev at lists.iotivity.org >> Subject: RE: Jenkins build timeout plugin >> >> >> >> >> Bill, >> >> >> >> That makes sense. I am going to start by applying gross numbers to >> each of the steps and then refine. >> >> For instance, what was the last item that hung the job? I can go add a >> timeout to that step. >> >> >> >> Pat >> >> >> >> From: Dieter, William R >> Sent: Monday, March 23, 2015 11:04 PM >> To: Lankswert, Patrick; iotivity-dev at lists.iotivity.org >> Subject: RE: Jenkins build timeout plugin >> >> >> >> >> Pat, >> >> >> >> I have not used the plugin before. There is an open bug against the >> build-timeout plugin complaining that no output is written to the >> console log when a build is killed for taking too long. So, when a >> job is killed, the developer looking at the console output would have >> to realize that the job was running for a long time and assume it was >> probably killed because of that. Granularity is at the Jenkins job >> level. >> >> >> >> Maybe it would make sense to do both. The verification builds are >> running prior to code review. We could set the Jenkins build-timeout >> plugin to catch cases where the build runs for 30 minutes or more >> because someone forgot to use ?timeout ?k?, but should have. That is >> well outside the current 6 sigma build time range, and could be >> adjusted upwards if builds start taking significantly longer. >> >> >> >> Bill. >> >> >> >> >> _______________________________________________ >> iotivity-dev mailing list >> iotivity-dev at lists.iotivity.org >> https://lists.iotivity.org/mailman/listinfo/iotivity-dev > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
