Skip to main content
Jump to: navigation, search


< Platform-releng
Revision as of 11:48, 2 September 2010 by (Talk | contribs) (Common build failures)

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/eclipse37/runIBuild

Nightly builds run from HEAD of org.eclipse.releng

0 20 * * 1,2,3,5,0 cd /builds; /home/users/releng/buildTools/eclipse37/runNBuild-skipPerf
0 20 * * 4,6 cd /builds; /home/users/releng/buildTools/eclipse37/runNBuild-skipPerf

3.5.x maintenance builds run from R3_6_maintenance branch of org.eclipse.releng

0 8 * * 3 cd /builds; /home/users/releng/buildTools/eclipse36x/runMBuild

The machines used in the builds and their locations are listed in the FAQ.

A script runs once a week to clean the test machines

0 18 * * 0 /home/users/releng/buildTools/scripts/

3.5.x test builds

cd /builds; /home/users/releng/buildTools/eclipse35x/runMKimBuildTest

3.4.2 test builds

cd /builds;  /home/users/releng/buildTools/eclipse34x/runKimTestMBuild

3.2.x test builds

cd /builds; /home/users/releng/buildTools/eclipse32x/runMTestBuild-skipPerf

Build scripts

Here is an overview of the build scripts used in the build.

As mentioned above, the builds are initiated by cron.

The integration build is run as follows

# !/bin/sh

cd /builds

command="/home/users/releng/buildTools/eclipse36/ -notify -buildDirectory /builds/I -tagMapFiles -compareMaps -sign -updateSite /builds/transfer/files/updates/3.6-I-builds I"

/home/users/releng/buildTools/extraTools/ $command

You will notice that the integration build has a compareMaps flag passed to the build. This paramater takes the current version of the map file project, and compares it to the version here in the the file "/home/users/releng/buildTools/eclipse36/"

-bash-3.00$ cat /home/users/releng/buildTools/eclipse36/


The bootstrap script that initiates 3.6 stream builds is located on the build machine here...


If you look search for "buildProjectTags" in this file, you'll see something like this This indicates the tag of the the three releng projects (org.eclipse.releng.eclipsebuilder, org.eclipse.releng.basebuilder, eclipseInternalBuildTools) used to run the build. If you need to run the build with a new version of the builder, update this tag. buildProjectTags=v20100430


The build is rsynced from eclipsebuildserv to to Look in kmoir's crontab for the scripts.

Common build failures

  • Fail to fetch bundles from Orbit - symptom - java net url timeout in build failure message. Start a new build -> 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 are usually redirected from to by the foundation. This redirection can be avoided by changing the url in the from to 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.
  • Build doesn't proceed - connent not updated etc.  Check for stale cvs checkouts on eclipsebuildserv.  ps -ef | grep cvs.  If there is a cvs connection that's over an hour old, kill it and allow the build to proceed.
  • 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.
  • 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
  • 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.
  • Message "Build failed, map files unchanged". This means either one of two things. One - a build ran and the map files were unchanged so it didn't need to run. Two - you restarted a failed build but the map files didn't change. In the second case, you should update this /home/users/releng/buildTools/eclipse36/ to reflect the build id of the last successful build.
  • Message "A problem occured while invoking the director". If there is a compile error in the build, the bundle with the compile error will not be published to the repository. Thus when the director is invoked to build zips, the director operation will fail.
  • The director logs, mirror logs etc. are located on the test results pages, under release engineering logs. Example of 3.6 release engineering logs.
  • All build tasks are invoked via the userid kmoir

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

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

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.

Restarting the build

Each build has a corresponding directory on eclipsebuildserv in /builds. For instance /builds/I201004291549/. If you cd to the org.eclipse.releng.eclipsebuilder directory, there is a script called buildAll.xml. The main target looks something like this

<target name="main" depends="init">
                <antcall target="buildEclipseSourceDrops" />
                <antcall target="buildMasterFeature" />
                <parallel failonany="true">
                                <antcall target="updatePackProperties" />
                                <antcall target="signMasterFeature" />
                                <antcall target="buildSdkTestFeature" />
                                <ant antfile="${}/../helper.xml" target="verifyCompile" />
                <parallel failonany="true">
                                <antcall target="packageEclipseDistributables" />
                                <ant antfile="${}/equinox.prov/run.xml" />
                                <antcall target="packageRepos" />
                                <antcall target="packageEquinoxDistributables" />

                                <antcall target="apiTooling" />
                                <antcall target="publishEclipse" />
                                <antcall target="publishEquinox" />
                        <antcall target="testEclipse" />
                <antcall target="publishRSS" /> 

If the build fails, you can restart it by commenting out the sections of the build that have already completed in the main target. Then cd to /builds/I201004291549/org.eclipse.releng.eclipsebuilder, for example, and run sh command.txt. This will allow the build to continue. Alternatively, you can add a cron entry to restart the build. For example,

36 20 * * 3 cd /builds/I201004291549/org.eclipse.releng.eclipsebuilder; sh command.txt

It's better to start the build from cron if you need the tests to proceed without having to retain your ssh session.

Back to the top