flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <cfram...@adobe.com>
Subject Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
Date Thu, 24 Jan 2013 15:38:41 GMT
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

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.


On 1/24/13 1 :42AM, "Alex Harui" <aharui@adobe.com> wrote:

>On 1/23/13 10:20 PM, "Justin Mclean" <justin@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.

View raw message