I agree in the normal daily build scenario we should not be doing the thirdparty-downloads. I know I've suggested this several times in the past.
Perhaps once a week we can clean out the thirdparty-downloads and refetch them all to verify that part of the build process. The easiest way to modify the build script is to add an unless="no.thirdparty-clean" to the thirdparty-clean target. That way you can always use the release target, with -Dno.thirdparty-clean= on a daily basis and remove the switch once a weekly basis. Carol On 1/24/13 1 :42AM, "Alex Harui" <aha...@adobe.com> wrote: > > > >On 1/23/13 10:20 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >> Hi, >> >>>> https://builds.apache.org/job/Flex_SDK_checkin_tests/98/console >>> Yeah, but the prior 3 were download failures which is why I didn't >>>even read >>> 98. >> >> Also from what I can see 96 and 87 worked: >> https://builds.apache.org/job/Flex_SDK_checkin_tests/ >> >> There's been no download failures for the check in tests in the last >>few days >> that I'm aware of. >> >> For the Flex SDK there only been one recent failure yesterday (465) >>which was >> a download failure. >Hmm, I just sorted my mailbox by "Apache Jenkins Server". >I see (over about a 13 hour period): >Passed for 99 >Passed for 466 >Failed 98 >Failed 465 >Failed 455 > >I believe all 3 to be false failures. That is too unreliable a system for >me. Not having to download stuff would probably make the system much more >reliable. Not sure what to do about a checkintest choke. > >-- >Alex Harui >Flex SDK Team >Adobe Systems, Inc. >http://blogs.adobe.com/aharui >
