View source for 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, [[User:Naci Dai|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 [[http://www.march-hare.com/cvspro]].
* zip/unzip - If you are using Windows, you will need the commandline zip/unzip. You can get it from [[http://www.info-zip.org/UnZip.html]]

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:
[http://download.eclipse.org/stp/committers].

When a build is declared (i.e. becomes official), it is moved to [http://download.eclipse.org/stp/downloads].  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 [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 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 <b>build.eclipse.org</b>. 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 <b>/shared/stp/</b>. 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. 
[http://www.eclipse.org/equinox/documents/plugin-versioning.html Plugin Versioning]

Very helpful guide to builds and automatic testing. 
[http://www.eclipse.org/articles/Article-PDE-Automation/automation.html Build and Test Automation for plug-ins and features]

Good step-by-step on how to do updates. [http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html How To Keep Up To Date]

We base our builds on the Eclipse platform's "basebuilder". 
[http://wiki.eclipse.org/index.php/Platform-releng 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 [[https://bugs.eclipse.org/bugs/attachment.cgi?id=26584 attachment]] to [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=108259 bug 108259]]

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

And ... never forget [http://help.eclipse.org/help31/index.jsp Eclipse Help] ... search for things related to update manager, PDE, features, site.xml, etc.