Hi,
> Perhaps once a week we can clean out the thirdparty-downloads and refetch
> them all to verify that part of the build process.
I've added a weekly build as well that does a full check out and download 3rd
party bits. Just giving it a trail run.
https://builds.apache.org/job/Flex_SDK_downl
HI,
> In jenkins_build.xml, we call build.xml -> download task based on what
> jenkins.properties specifies. No need to modify build.xml
No we needed to modify it. The issue is that setup for the release was removing
(correctly so) the 3rd party downloads and then downloading them again, this is
On Thu, Jan 24, 2013 at 9:11 PM, Justin Mclean wrote:
> Hi,
>
> > How about crafting a special jenkins_build.xml that calls the relevant
> > tasks from build.xml?
> We already have that to get the player global and AIR packages. So it
> could be possible for it to check and change the build option
Hi,
> How about crafting a special jenkins_build.xml that calls the relevant
> tasks from build.xml?
We already have that to get the player global and AIR packages. So it could be
possible for it to check and change the build options as required. But the main
build file would still need to chang
How about crafting a special jenkins_build.xml that calls the relevant
tasks from build.xml? jenkins_build.xml would have its own
jenkins.properties file.
This way, we wont have the hassle of checking in stuff that would affect
users who dont care about jenkins.
On Thu, Jan 24, 2013 at 8:59 PM,
Hi,
> I'm not sure I understood that, but could you add the option in
> build.properties?
There is no local build.properties file that we can easily edit on the Jenkins
box (as we have no access) and we wouldn't want to put it in SVN as it would
then effect all builds. Initially Jenkins start wi
On 1/24/13 4:31 PM, "Justin Mclean" wrote:
> Hi,
>
>> 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 swit
Hi,
> 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.
Only issue I see with this is i
Hi Carol.
> The easiest way to modify the build script is to add an
> unless="no.thirdparty-clean" to the thirdparty-clean target.
Good idea I'll update the build scripts and change the Jenkins jobs.
Justin
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
On 1/23/13 10:20 PM, "Justin Mclean" 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_
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
Hi,
> I meant, can the build not try to download what it failed on 3 times early
> today? Can we store those downloads somewhere on the jenkins server?
I assume the clean (part of release) is cleaning out things it need and thus
it's doing a download again but not looked closely. I assume it's
On 1/23/13 10:02 PM, "Justin Mclean" wrote:
> Hi,
>
>> I think I saw three failure notices today all related to downloads so then I
>> stopped looking.
> The test failure didn't look like a download failure to me as it actually run
> to completion and failed on the mustella tests.
>
> https:
Hi,
> I think I saw three failure notices today all related to downloads so then I
> stopped looking.
The test failure didn't look like a download failure to me as it actually run
to completion and failed on the mustella tests.
https://builds.apache.org/job/Flex_SDK_checkin_tests/98/console
>
On 1/23/13 4:36 PM, "Justin Mclean" wrote:
> Hi,
>
>> No, I've been ignoring Jenkins because it keeps failing on downloads.
>
> It occasionally fails on downloads given we had something like 500 +
> successful run it's probably best to keep an eye on it.
I think I saw three failure notices t
Hi,
> No, I've been ignoring Jenkins because it keeps failing on downloads.
It occasionally fails on downloads given we had something like 500 + successful
run it's probably best to keep an eye on it.
Justin
No, I've been ignoring Jenkins because it keeps failing on downloads.
On 1/23/13 3:25 PM, "Om" wrote:
> Alex, are you looking into this?
>
> Thanks,
> Om
>
> -- Forwarded message --
> From: Apache Jenkins Server
> Date: Wed, Jan 23, 201
Alex, are you looking into this?
Thanks,
Om
-- Forwarded message --
From: Apache Jenkins Server
Date: Wed, Jan 23, 2013 at 2:26 PM
Subject: Build failed in Jenkins: Flex_SDK_checkin_tests #98
To: jus...@classsoftware.com, bigosma...@gmail.com, aha...@adobe.com
See <ht
19 matches
Mail list logo
