Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

STP Build Process and Procedures

Revision as of 15:37, 29 April 2006 by Ndai (Talk | contribs)

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).


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: [1].

When a build is declared (i.e. becomes official), it is moved to [2]. 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/webtools/. 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.

Back to the top