Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Platform-releng/Obsolete/Platform-releng-basics"
m |
|||
Line 1: | Line 1: | ||
− | == Basic overview of platform builds == | + | == Basic overview of platform builds == |
Integration builds are in crontab of build user on build machine | Integration builds are in crontab of build user on build machine | ||
Line 14: | Line 14: | ||
</pre> | </pre> | ||
The machines used in the [http://wiki.eclipse.org/Platform-releng-faq#What_hardware_comprises_the_platform-releng_build_infrastructure.3F builds] are listed in the FAQ. | The machines used in the [http://wiki.eclipse.org/Platform-releng-faq#What_hardware_comprises_the_platform-releng_build_infrastructure.3F builds] are listed in the FAQ. | ||
− | |||
− | |||
A script runs once a week to clean the test machines | A script runs once a week to clean the test machines | ||
Line 25: | Line 23: | ||
3.2.x test builds | 3.2.x test builds | ||
<pre>cd /builds; /home/users/releng/buildTools/eclipse32x/runMTestBuild-skipPerf | <pre>cd /builds; /home/users/releng/buildTools/eclipse32x/runMTestBuild-skipPerf | ||
− | </pre> | + | </pre> |
− | + | == Common build failures == | |
− | == Common build failures == | + | |
*Fail to fetch bundles from Orbit - symptom - java net url timeout in build failure message. Start a new build -> www.eclipse.org timeouts are intermittent. | *Fail to fetch bundles from Orbit - symptom - java net url timeout in build failure message. Start a new build -> www.eclipse.org timeouts are intermittent. | ||
Line 46: | Line 43: | ||
/builds/M200908251330/src/fetch_org.eclipse.equinox.p2.user.ui.xml:304: Error occurred while transforming repository. | /builds/M200908251330/src/fetch_org.eclipse.equinox.p2.user.ui.xml:304: Error occurred while transforming repository. | ||
</pre> | </pre> | ||
− | Since our build runs in an IBM lab, the http gets for orbit bundles from eclipse.org are usually redirected from download.eclipse.org to fullmoon.ottawa.ibm.com by the foundation. This redirection can be avoided by changing the url in the orbit.map from download.eclipse.org to www.eclipse.org/external. Sometimes it will take a day or so for the internal mirror to get the latest orbit build | + | Since our build runs in an IBM lab, the http gets for orbit bundles from eclipse.org are usually redirected from download.eclipse.org to fullmoon.ottawa.ibm.com by the foundation. This redirection can be avoided by changing the url in the orbit.map from download.eclipse.org to www.eclipse.org/external. Sometimes it will take a day or so for the internal mirror to get the latest orbit build. |
− | * | + | *Missing dependancies due to erroneous map file submission. Check that the map file refers to a version of a project that exists in the repo. If the version of a bundle in cvs doesn't match the one in the map files, ask team to resubmit and start a new build. |
− | *SDKs fail to provision due to missing dependancies. There are releng logs on each test results page of the build that provide logs of the from the call to the p2 director to provision the zips. The Equinox team is helpful in finding the cause of the problem. See this page for an example. http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/buildlogs.php | + | *SDKs fail to provision due to missing dependancies. There are releng logs on each test results page of the build that provide logs of the from the call to the p2 director to provision the zips. The Equinox team is helpful in finding the cause of the problem. See this page for an example. http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/buildlogs.php |
+ | *Missing dependancies due to errors in Manifest or missing dependancies in manifest. In the both cases, the error sent to the releng list will look something like http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg09778.html | ||
+ | *Dependancies expressed in manifest and feature don't match. This means that the p2 director cannot resolve the dependencies for the product it is trying to build. The resultant zips for that platform are 0 size. For instance, see bug [https://bugs.eclipse.org/bugs/show_bug.cgi?id=258489 | bug 258489]. Also, you can see the .log files that the directory built by following the ''Release Engineering build logs'' link off the ''Test results'' build page. | ||
− | + | <br> | |
− | + | ||
− | + | ||
+ | == Missing test results == | ||
− | + | *The test results page of the build isn't updated until all the test results have completed. To see what machines are currently being used for tests look the the following directory. There will be marker files that correspond to the machine operating system and build number. | |
− | + | ||
− | + | ||
<pre>-bash-3.00$ ls /home/users/releng/buildTools/markers/*.marker | <pre>-bash-3.00$ ls /home/users/releng/buildTools/markers/*.marker | ||
eclipse-macosx-M20090824-0800.marker | eclipse-macosx-M20090824-0800.marker | ||
Line 80: | Line 76: | ||
0=epwin2 | 0=epwin2 | ||
</pre> | </pre> | ||
− | The windows machines run tests via rsh. The linux and mac machines run tests via ssh. The windows machines need to be rebooted every so often. The old build artifacts are cleaned automatically by cron jobs. | + | The windows machines run tests via rsh. The linux and mac machines run tests via ssh. The windows machines need to be rebooted every so often. The old build artifacts are cleaned automatically by cron jobs. |
− | + | ||
*The windows tests machines crash every so often. The event logs don't indicate that anything is wrong with the build. They are on the KVM next to the Eclipse rack in lab, on number 5 and 6. They can just be rebooted and logged into as the build user. I usually reboot these machines once a week so this doesn't happen. | *The windows tests machines crash every so often. The event logs don't indicate that anything is wrong with the build. They are on the KVM next to the Eclipse rack in lab, on number 5 and 6. They can just be rebooted and logged into as the build user. I usually reboot these machines once a week so this doesn't happen. |
Revision as of 14:44, 25 August 2009
Basic overview of platform builds
Integration builds are in crontab of build user on build machine
Integration builds run from the tags of org.eclipse.releng
0 8 * * 2 cd /builds; /home/users/releng/buildTools/eclipse36/runIBuild
Nightly builds run from HEAD of org.eclipse.releng
0 20 * * 1,2,3,5,0 cd /builds; /home/users/releng/buildTools/eclipse36/runNBuild-skipPerf 0 20 * * 4,6 cd /builds; /home/users/releng/buildTools/eclipse36/runNBuild-skipPerf
3.5.x maintenance builds run from R3_5_maintenance branch of org.eclipse.releng
0 8 * * 3 cd /builds; /home/users/releng/buildTools/eclipse35x/runMBuild
The machines used in the builds are listed in the FAQ.
A script runs once a week to clean the test machines
0 18 * * 0 /home/users/releng/buildTools/scripts/buildblaster.sh
Older builds 3.4.2 test builds run from tags in 3.4.x maintenance branch
cd /builds; /home/users/releng/buildTools/eclipse34x/runKimTestMBuild
3.2.x test builds
cd /builds; /home/users/releng/buildTools/eclipse32x/runMTestBuild-skipPerf
Common build failures
- Fail to fetch bundles from Orbit - symptom - java net url timeout in build failure message. Start a new build -> www.eclipse.org timeouts are intermittent.
- "Error occurred while transforming repository" usually means that the bundle couldn't be fetched from Orbit. For example
Build M20090825-1330 (Timestamp: 200908251330): The following error occurred while executing this line: /builds/M200908251330/org.eclipse.releng.eclipsebuilder/buildAll.xml:166: The following error occurred while executing this line: /builds/M200908251330/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.5.1.R35x_20090721/scripts/build.xml:78: The following error occurred while executing this line: /builds/M200908251330/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/master/customTargets.xml:18: The following error occurred while executing this line: /builds/M200908251330/org.eclipse.releng.eclipsebuilder/eclipse/buildConfigs/master/allElements.xml:16: The following error occurred while executing this line: /builds/M200908251330/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.5.1.R35x_20090721/scripts/genericTargets.xml:59: The following error occurred while executing this line: /builds/M200908251330/src/fetch_master.xml:11: The following error occurred while executing this line: /builds/M200908251330/src/fetch_master.xml:73: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.sdk.xml:11: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.sdk.xml:41: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.platform.xml:11: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.platform.xml:904: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.equinox.p2.user.ui.xml:10: The following error occurred while executing this line: /builds/M200908251330/src/fetch_org.eclipse.equinox.p2.user.ui.xml:304: Error occurred while transforming repository.
Since our build runs in an IBM lab, the http gets for orbit bundles from eclipse.org are usually redirected from download.eclipse.org to fullmoon.ottawa.ibm.com by the foundation. This redirection can be avoided by changing the url in the orbit.map from download.eclipse.org to www.eclipse.org/external. Sometimes it will take a day or so for the internal mirror to get the latest orbit build.
- Missing dependancies due to erroneous map file submission. Check that the map file refers to a version of a project that exists in the repo. If the version of a bundle in cvs doesn't match the one in the map files, ask team to resubmit and start a new build.
- SDKs fail to provision due to missing dependancies. There are releng logs on each test results page of the build that provide logs of the from the call to the p2 director to provision the zips. The Equinox team is helpful in finding the cause of the problem. See this page for an example. http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/buildlogs.php
- Missing dependancies due to errors in Manifest or missing dependancies in manifest. In the both cases, the error sent to the releng list will look something like http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg09778.html
- Dependancies expressed in manifest and feature don't match. This means that the p2 director cannot resolve the dependencies for the product it is trying to build. The resultant zips for that platform are 0 size. For instance, see bug | bug 258489. Also, you can see the .log files that the directory built by following the Release Engineering build logs link off the Test results build page.
Missing test results
- The test results page of the build isn't updated until all the test results have completed. To see what machines are currently being used for tests look the the following directory. There will be marker files that correspond to the machine operating system and build number.
-bash-3.00$ ls /home/users/releng/buildTools/markers/*.marker eclipse-macosx-M20090824-0800.marker eclipse-rhelws5-6.0-M20090824-0800.marker eclipse-rhelws5-M20090824-0800.marker eclipse-rhelws5-perf-M20090824-0800.marker eclipse-sled10-perf-M20090824-0800.marker eclipse-win32xp-6.0-M20090824-0800.marker eclipse-win32xp-M20090824-0800.marker eclipse-win32xp-perf-M20090824-0800.marker
If you cat the marker files you can see the hostname of the machine that corresponds to the marker file
-bash-3.00$ cat /home/users/releng/buildTools/markers/*.marker 0=lb6mac 0=ejlnx2 0=ejlnx1 0=eplnx2 0=eplnx1 0=ejwin2 0=ejwin1 0=epwin2
The windows machines run tests via rsh. The linux and mac machines run tests via ssh. The windows machines need to be rebooted every so often. The old build artifacts are cleaned automatically by cron jobs.
- The windows tests machines crash every so often. The event logs don't indicate that anything is wrong with the build. They are on the KVM next to the Eclipse rack in lab, on number 5 and 6. They can just be rebooted and logged into as the build user. I usually reboot these machines once a week so this doesn't happen.