Common Build Infrastructure/Getting Started

This information is preliminary and subject to change. If you see an error or omission, please feel free to edit it.

Create Configuration Project

The first step is to create a project (often called a .releng project) to house your configuration settings. Here are some sample projects to get you started.

At its simplest, this is:

• build.properties -- settings for the build
• maps/build.map -- where to fetch sources (you can have as many .map files as you need)

However, you will likely need to feed in extra dependencies to the build, if it requires more than just the Eclipse "Classic" SDK to build (ie, JDT, PDE, CVS).

• buildExtra.xml -- extra inputs and packaging steps

You will likely also want to run automated tests as part of your build. For this you'll need:

• testing.properties -- properties specific to running tests

Finally, to control how your build is published, you'll need another properties file:

• promote.properties -- properties specific to publishing builds

Check all these files into CVS or SVN.

Set Up Locally

To set up the local bootstrapping required to run a build, you can run this script: localhost.setup.sh. Note that this script is currently only supported on Fedora 10. We're looking for testers to try it out on other linuxes and on Windows via cygwin. If you can't get it working, use it as a checklist for the manual steps required to get your local machine set up to build.

Once you've set up your environment, you should have something like this: 3rdPartyJars/ [libraries and 3rd party jars] downloads/ [dependencies, cached and reused] scripts/ [build system scripts & tools] org.eclipse.dash.common.releng_HEAD/ [a specific version of o.e.d.c.releng] org.eclipse.dash.common.releng/ [a symlink to the above] org.eclipse.releng.basebuilder_R35_M2/ [a specific version of o.e.r.bb] org.eclipse.releng.basebuilder/ [a symlink to the above]

Run A Build

Builds are run though start.sh, which sets up configuration variables and invokes Eclipse's AntRunner to run the build. Testing is done by having this ant thread call into the shell to start a new Eclipse thread on a different display (or one day, a remote machine). As such, there is still some dependency on bash scripting for the build system to work. We plan to remove this dependency over time.

Here's a sample invokation of start.sh -- read the source for other examples, or check out the README.txt files in the other sample projects:

cd /opt/public/cbi/build/org.eclipse.dash.common.releng_HEAD; \
cvs up -Pd; cd tools/scripts;./start.sh -projectid tools.gef -version 3.4.0 -buildType N \
 -projRelengRoot ':pserver:anonymous@dev.eclipse.org:/cvsroot/technology' \
 -projRelengPath 'org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.gef.releng' \
 -basebuilderBranch R35_M2 -javaHome /opt/public/common/ibm-java2-142 \
 -URL http://download.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/eclipse-SDK-3.4-linux-gtk.tar.gz \
  2>&1 | tee /opt/public/cbi/logs/buildlog_`date +%H%M%S`.txt

• To run locally, see examples in start.sh.

Debug Build

Here are some general tips for finding log files and sifting the build's tea leaves:

• Always log to a file, preferably a unique one. You can watch console output AND log to file (standard out and standard error) with this:

start.sh ... 2>&1 | tee /opt/public/cbi/logs/buildlog_`date +%H%M%S`.txt

• You can also use this, which will dump a log in your build's folder for you:

start_logger.sh

• Logs can be found in the build's folder like this:

find /path/to/build/folder -type f -name "*log" -o -name "*log.txt" -o -name "*log.zip"

• Search logs for keywords like "ERROR" and "FAIL" to see what went wrong

• Chances are if something really bad happened, it occurred in the first or last 100 lines of the log.

See Also

• Build Problem FAQ
• Testing Problem FAQ