Jump to: navigation, search

Difference between revisions of "MoDisco/Releng/How to Use"

Line 1: Line 1:
 +
The MoDisco project is built using [[Athena Common Build]], with this [http://dev.eclipse.org/svnroot/modeling/org.eclipse.gmt.modisco/releng/trunk/org.eclipse.gmt.modisco.releng releng project].
 +
 +
== What is built? ==
 +
In the build.properties file of the releng project, the "mainFeatureToBuildID" property defines the feature that must be built. This feature must include all other features that must be built.
 +
 +
The releng project contains map files, which specify how to get the plugins and features that are to be built. For each plugin or feature, the map defines its location on a version control system (CVS and SVN are supported), and the version that must be used. Nightlies ignore the version information, and always build from head, whereas other types of builds checkout the tag or branch specified in the map.
 +
 
== How to start a build? ==
 
== How to start a build? ==
  
Line 19: Line 26:
 
== How to publish a build? ==
 
== How to publish a build? ==
 
=== Automatically ===
 
=== Automatically ===
Successful nightly and integration builds are automatically published to download.eclipse.org. For example, a nightly build for version 0.8.0, created on October 6 2009 at 11:54 EST would be published to:
+
Successful '''N'''ightly and '''I'''ntegration builds are automatically published to download.eclipse.org. For example, a nightly build for version 0.8.0, created on October 6 2009 at 11:54 EST would be published to:
 
  http://download.eclipse.org/modeling/gmt/modisco/downloads/drops/0.8.0/N200910061154
 
  http://download.eclipse.org/modeling/gmt/modisco/downloads/drops/0.8.0/N200910061154
 
These builds can then be seen and downloaded from [http://www.eclipse.org/gmt/modisco/downloads/ http://www.eclipse.org/gmt/modisco/downloads/], where additional information is available (test results, build log, build configuration, build dependencies).
 
These builds can then be seen and downloaded from [http://www.eclipse.org/gmt/modisco/downloads/ http://www.eclipse.org/gmt/modisco/downloads/], where additional information is available (test results, build log, build configuration, build dependencies).

Revision as of 09:36, 7 October 2009

The MoDisco project is built using Athena Common Build, with this releng project.

What is built?

In the build.properties file of the releng project, the "mainFeatureToBuildID" property defines the feature that must be built. This feature must include all other features that must be built.

The releng project contains map files, which specify how to get the plugins and features that are to be built. For each plugin or feature, the map defines its location on a version control system (CVS and SVN are supported), and the version that must be used. Nightlies ignore the version information, and always build from head, whereas other types of builds checkout the tag or branch specified in the map.

How to start a build?

Automatically

  • Nightly builds are run every 6 hours everyday, at 02:10, 08:10, 14:10 and 20:10 EST, if SVN changed since the last build.
  • Integration builds are started every Tuesday at 06:36 EST (11:36 or 12:36 GMT), if the releng project changed since the last integration build.

Manually

Then:

  • In Hudson, click on Build Now, change the build parameters as needed (see #Build parameters), and click on Build.
  • You can then click on the job name in the Build History section in the left column, and then on Console Output, to follow build progress in real time.

How to publish a build?

Automatically

Successful Nightly and Integration builds are automatically published to download.eclipse.org. For example, a nightly build for version 0.8.0, created on October 6 2009 at 11:54 EST would be published to:

http://download.eclipse.org/modeling/gmt/modisco/downloads/drops/0.8.0/N200910061154

These builds can then be seen and downloaded from http://www.eclipse.org/gmt/modisco/downloads/, where additional information is available (test results, build log, build configuration, build dependencies).

Manually

Stable, Maintenance and Release builds are not automatically published. They should be first tested internally before publishing. For example, to publish the 0.8.0M2 milestone build:

  • First, fetch the build archive to test:
scp -r <commiterid>@build.eclipse.org:/opt/users/hudsonbuild/.hudson/jobs/cbi-modisco-integration/lastSuccessful/archive/build/* .
  • Then, test the build locally
  • Then, publish it:
ssh <commiterid>@build.eclipse.org
cd /opt/users/hudsonbuild/.hudson/jobs/cbi-modisco-integration/lastSuccessful/archive/build/
cp -r S200910061155 /home/data/httpd/download.eclipse.org/modeling/gmt/modisco/downloads/drops/0.8.0/
  • Finally, for a release, update the update site with the new build:
rm -rf /home/data/httpd/download.eclipse.org/modeling/gmt/modisco/update/release/*
unzip S200910061155/MODISCO-Update-incubation-0.8.0M2.zip -d /home/data/httpd/download.eclipse.org/modeling/gmt/modisco/update/release/
* Check that the new build appears on http://www.eclipse.org/gmt/modisco/downloads/.

Build parameters

Hudson builds expect these parameters:

  • PROJECTID : modeling.gmt.modisco : no reason to change this
  • VERSION : the version being built, must also be set in the releng project's promote-N.properties and promote-I.properties.
  • BUILDTYPE : the kind of build, represented by a code letter (see this page):
    • N: Nightly
    • I: Integration
    • M: Maintenance (NOT milestone)
    • S: Stable (for Milestones and Release Candidate builds)
    • R: Release
  • EXTRAFLAGS : flags that are passed to the build start script (see start.sh). Useful flags are:
    • -buildAlias : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add -buildAlias 0.8.0M2 to get "MODISCO-SDK-incubation-0.8.0M2.zip" instead of "MODISCO-SDK-incubation-S200910070943.zip".
    • -forceContextQualifier : force the ".qualifier" part of a plugin version number to a specific string.
    • -fetchTag : Force a specific tag to be used when pulling sources from the VCS. For example, use -fetchTag HEAD to build from HEAD instead of from the versions specified in the releng project's map files.
    • -localSourceCheckoutDir : checkout the sources from a local directory instead of from the VCS. Since the Hudson nightly job is configured to check source changes before starting the build, this option is used to reuse Hudson's checked out sources.