Difference between revisions of "Common Build Infrastructure/Getting Started"

Revision as of 14:39, 26 November 2008

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 to house your configuration settings. 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 (that is, 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

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

• promote.properties

Check all these files into CVS or SVN.

Local Setup

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.

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.

Debugging Build Output

These 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

• 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