Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
On 1/24/13 4:31 PM, Justin Mclean jus...@classsoftware.com 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 switch once a weekly basis. Only issue I see with this is if a non download job fails and Jenkins decides to rebuild it's workspace every run from that point on with fail and will need to be fixed by hand by removing the -Dno.thirdparty-dowbload option. I'm not sure I understood that, but could you add the option in build.properties? Then if we think we need to remove that option to fix it, we don't have to learn jenkins, we can just edit the build.properties? On a related note, is there a way to ask Jenkins to simply 'try again'? If checkintest chokes again, it might just need to run a build again. Back in the day, we had a file called kick-build.txt in the root that we'd modify and check in to do that. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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 with a clean slate and checks out everything from SVN. Then if we think we need to remove that option to fix it, we don't have to learn jenkins, we can just edit the build.properties? Don't think so see above. I could have the build script generate a build.properties file but that seem a little silly. On a related note, is there a way to ask Jenkins to simply 'try again'? Yes but it would fail again, if the files are not there it will fail each time until we change to build options to download the files. Back in the day, we had a file called kick-build.txt in the root that we'd modify and check in to do that. Any checkin will trigger a build and run of the check in texts (once per hour max). You can also manually run builds. Justin
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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, Justin Mclean jus...@classsoftware.comwrote: 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 with a clean slate and checks out everything from SVN. Then if we think we need to remove that option to fix it, we don't have to learn jenkins, we can just edit the build.properties? Don't think so see above. I could have the build script generate a build.properties file but that seem a little silly. On a related note, is there a way to ask Jenkins to simply 'try again'? Yes but it would fail again, if the files are not there it will fail each time until we change to build options to download the files. Back in the day, we had a file called kick-build.txt in the root that we'd modify and check in to do that. Any checkin will trigger a build and run of the check in texts (once per hour max). You can also manually run builds. Justin
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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 specified in build.xml. We wanted to stop that from happening so that they are not downloaded every time when run in Jenkins. I've made the changes and it now working the SDK and check test build will no longer download the 3rd party files so there should be far less failures and the builds a little quicker. (As long as the workspaces are not removed). Thanks, Justin
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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_download_build/ Thanks, Justin
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
No, I've been ignoring Jenkins because it keeps failing on downloads. On 1/23/13 3:25 PM, Om bigosma...@gmail.com wrote: Alex, are you looking into this? Thanks, Om -- Forwarded message -- From: Apache Jenkins Server jenk...@builds.apache.org 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 https://builds.apache.org/job/Flex_SDK_checkin_tests/98/changes Changes: [aharui] add test to clean up so tests in the following .mxml file don't throw exceptions -- [...truncated 1191 lines...] [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\to ol\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\tool.swc (48620 bytes) main: automation: bundles-clean: clean: compile: [echo] Compiling frameworks/libs/automation/automation.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\automation.swc (86305 bytes) main: [echo] Compiling frameworks/locale/en_US/automation_rb.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation\bundle-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\locale\en_U S\automation_rb.swc (2136 bytes) tool_air: bundles-clean: [echo] IN bundles clean tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: tool_air_bundles-clean: clean: compile: [echo] Compiling tool_air.swc [echo] Using https://builds.apache.org/job/Flex_SDK_checkin_tests/ws/air/AIR Integration Kit/frameworks/libs/air/airglobal.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\to ol_air\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\tool_air.swc (67364 bytes) main: automation_spark: clean: compile: [echo] Compiling frameworks/libs/automation/automation_spark.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation_spark\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\automation_spark.swc (87260 bytes) main: automation_flashflexkit: clean: compile: [echo] Compiling frameworks/libs/automation/automation_flashflexkit.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation_flashflexkit\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\automation_flashflexkit.swc (7357 bytes) main: automation_air: clean: compile: [echo] Compiling frameworks/libs/automation/automation_air.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation_air\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\automation_air.swc (16068 bytes) main: automation_airspark: clean: compile: [echo] Compiling frameworks/libs/automation/automation_airspark.swc [echo] Using https://builds.apache.org/job/Flex_SDK_checkin_tests/ws/air/AIR Integration Kit/frameworks/libs/air/airglobal.swc [compc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\projects\au tomation_airspark\compile-config.xml [compc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\libs\automa tion\automation_airspark.swc (4562 bytes) main: javascript: clean: compile-swfs: [echo] Compiling https://builds.apache.org/job/Flex_SDK_checkin_tests/ws/frameworks\javascript/ FABridge/samples/EmptySwf.as [mxmlc] Loading configuration file F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\flex-config .xml [mxmlc] F:\hudson\hudson-slave\workspace\Flex_SDK_checkin_tests\frameworks\javascript\ FABridge\samples\EmptySwf.swf (5755 bytes) [echo] Compiling
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
On 1/23/13 4:36 PM, Justin Mclean jus...@classsoftware.com 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 today all related to downloads so then I stopped looking. Is there no precedence for storing these downloads somewhere, or not deleting them? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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 Is there no precedence for storing these downloads somewhere, or not deleting them? It only keeps the last couple of build so no real issue there that I can see. We could use them as nightly builds as it does automatically make a source and binary distribution which may be useful given our progress on regular releases. Thanks, Justin
Re: Build failed in Jenkins: Flex_SDK_checkin_tests #98
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
