STP Build Process and Procedures

This page is to collect general information and references about the STP build process and procedures. STP build process is refactored from WTP Build Process and Procedures, so you can also use the information found in those pages.

Thanks, Naci Dai, 29 April 2006

Build Schedules

STP builds are currently running on a trial basis. There is no build schedule.

However, a typical weekly I-Build needs contributions to be released by EOD Wednesday's, we smoke test that build on Thursday's, and to declare it by Friday's at noon (eastern time).

Running Build Locally

Running a local build is quite straighforward, but needs some build-mastery. Before you attempt a local build, make sure that you have some of the build prerequisites setup on your machine:

• CVS - you will need a cvs client installed on your machine. Build needs to find it on your path. You can get it from [[1]].
• zip/unzip - If you are using Windows, you will need the commandline zip/unzip. You can get it from [[2]]

To run the build, first checkout the build module from STP CVS.

  cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/stp co build

Then, go into the folder build/cruise. Review the contents of the build.properties file. Edit them to match your choices. baseos is linux, macos, win32, etc. basews is gtk, win32, basearch is ppc, x86. You can find all supported configuration from eclipse base platform. Set the build.home to where you want all workdirs and steup files to be copied. And, you should have an internet connection before you start the build.

  build.home=/shared/stp
  mapCvsRoot=:ext:ndai@dev.eclipse.org:/cvsroot/stp
  baseos=linux
  basews=gtk
  basearch=ppc

Once you have the properties set, just run ant with the build file named build.xml and watch it build one components after the other, test, create a website etc.

Be warned that unless you are the build master, you will see two failures during the build: First it will not be able to send a notice email, and second it will not be able to upload your build to the downloads area. These failues are normal if you are doing a local build.

Build mechanics

The platform's releng tool should be used to "release" projects to the map files. The release is done with:

• commiting changes to CVS.
• tagging the module (plugin or feature) using the versining standard described below
• release the tagged verion by modifying the corresponding map file in build/releng/maps

The releng module is monitored by cruisecontrol. Whenever there is change a new build will automatically trigger. Once teh build is complete, it is automatically delievered to: [3].

When a build is declared (i.e. becomes official), it is moved to [4]. The declaration process is manual.

As projects are versioned, please use the "standard" format, in UTC time, following vYYYYMMDDHHMM. This is important as these cvs tags become the qualifier field of the plugin's version.

Note: do NOT use underscores in the CVS version, as there are some issues with Eclispe tooling when it finds an underscore in a plugin or version qualifier, see [89428].

How to watch the builds

Do you enjoy watching screens of console logs fly by as much as I? Waiting for that joyous final result? Well then you too can do that with the following information.

We are currently doing our builds on build.eclipse.org. Any committer can logon to that server using their committer ID and password. I use something like

  ssh ndai@build.server.org

Once there the main work we do is in /shared/stp/. If you want to "watch" the console log while the compiiler and ant files are running, you can use

   tail -f /shared/stp/build/cruise/cruise.out -n200

to watch the last part of the main log (during compile, etc.). This is the fastest way to find out if the build failed. Once it does fail, there's some diagnostic messages that might be informative in the last 20 or 50 lines. (Do be careful, though, the build always says "Build Successful" as its very very last message, and that message just means all the ant scripts were any to completely execute (not that they did so successfully).

During tests, you can watch test results console at,

   tail -f /shared/stp/test-stp-I/results/consolelogs/stptestlog.txt -n200

Background and Further Reading References

We in STP following the basic process and recommendations for versioning as the base Eclipse platform. Plugin Versioning

Very helpful guide to builds and automatic testing. Build and Test Automation for plug-ins and features

Good step-by-step on how to do updates. How To Keep Up To Date

We base our builds on the Eclipse platform's "basebuilder". Platform-releng

With our STP specific needs addressed in the STP project called build/releng.stpbuilder. While slightly out of date, the concepts are described see the [attachment] to [bug 108259]

Our basic server configuration and cruise control triggers is handled by the STP project build/cruise directory.

And ... never forget Eclipse Help ... search for things related to update manager, PDE, features, site.xml, etc.