Jump to: navigation, search

Difference between revisions of "EEF/Releng Guide"

< EEF
Line 11: Line 11:
  
 
* Integration builds are started every Tuesday at 18:12 EST, even if there is no modification on CVS.
 
* Integration builds are started every Tuesday at 18:12 EST, even if there is no modification on CVS.
 
{{warning|Builds Differences| Be careful on what is build. Nightly builds are built against CVS HEAD, and integration are built against CVS v0_7_1_BRANCH.}}
 
  
 
=== Manually ===
 
=== Manually ===
  
 
* Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )
 
* Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )
* Nightly build : go to the [https://build.eclipse.org/hudson/job/cbi-emf-eef-0.7-nightly/ nightly job]
+
* Nightly build : go to the [https://build.eclipse.org/hudson/job/emf-eef-nightly/ nightly job]
* Integration build : go to the [https://build.eclipse.org/hudson/job/cbi-emf-eef-0.7-integration/ integration job]
+
* Integration build : go to the [https://build.eclipse.org/hudson/job/emf-eef-integration/ integration job]
  
 
Then:
 
Then:
Line 30: Line 28:
  
 
  # daily N EEF builds
 
  # daily N EEF builds
  45 22 * * * bash /opt/users/hudsonbuild/.hudson/jobs/cbi-emf-eef-0.7-nightly/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-N.sh
+
  45 22 * * * bash /opt/users/hudsonbuild/.hudson/jobs/emf-eef-nightly/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-N.sh
 
  # weekly I EEF builds
 
  # weekly I EEF builds
  12 19 * * 2 bash /opt/users/hudsonbuild/.hudson/jobs/cbi-emf-eef-0.7-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh
+
  12 19 * * 2 bash /opt/users/hudsonbuild/.hudson/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh
  
 
The called scripts ( available [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.eef/releng/?pathrev=MAIN&root=Modeling_Project here]) unpack the update sites in the correct places, and copies the necessary files in correct places, too.
 
The called scripts ( available [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.eef/releng/?pathrev=MAIN&root=Modeling_Project here]) unpack the update sites in the correct places, and copies the necessary files in correct places, too.
Line 48: Line 46:
 
== Build parameters ==
 
== Build parameters ==
 
Hudson builds expect these parameters:
 
Hudson builds expect these parameters:
* PROJECTID : modeling.emf.eef : no reason to change this
+
* PROJECTID : modeling.emft.eef : no reason to change this
 
* VERSION : the version being built.
 
* VERSION : the version being built.
 
* BUILDTYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):
 
* BUILDTYPE : the kind of build, represented by a code letter (see [http://www.eclipse.org/modeling/downloads/build-types.php this page]):

Revision as of 09:11, 6 July 2010

Back to EEF


EEF Releng HOW TO

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

How to start a build?

Automatically

  • Nightly builds are run every 6 hours everyday, at 03:41, 09:41, 15:41 and 21:41 EST, monitoring every change in CVS.
  • Integration builds are started every Tuesday at 18:12 EST, even if there is no modification on CVS.

Manually

  • Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )
  • Nightly build : go to the nightly job
  • Integration build : go to the integration job

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. These promote actions are done by a cron job on the build server :

# daily N EEF builds
45 22 * * * bash /opt/users/hudsonbuild/.hudson/jobs/emf-eef-nightly/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-N.sh
# weekly I EEF builds
12 19 * * 2 bash /opt/users/hudsonbuild/.hudson/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh

The called scripts ( available here) unpack the update sites in the correct places, and copies the necessary files in correct places, too.

These builds can then be seen and downloaded from the EMFT download page, where additional information is available (test results, build log, build configuration, build dependencies).

See also the EEF Installation page to use the update sites if wanted.

Manually

Stable, Maintenance and Release builds are not automatically published. They should be first tested internally before publishing. After testing, you should use the specific promote script to promote in the right place.

Warning2.png
promote Milestones build
This last script update also the helios build train. use it with caution !


Build parameters

Hudson builds expect these parameters:

  • PROJECTID : modeling.emft.eef : no reason to change this
  • VERSION : the version being built.
  • 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

For Integration builds, you can modify these parameters :

  • BUILDALIAS : for release, maintenance and stable builds, use this option to give a more meaningful name to the build. For example, add 0.8.0M2 to get "EEF-SDK-incubation-0.8.0M2.zip" instead of "EEF-SDK-incubation-Sxxxx.zip".
  • FETCHTAG : Force a specific tag to be used when pulling sources from CVS. For example, use HEAD to build from HEAD instead of from the versions specified in the releng project's map files.

It is also possible to modify the configuration of the jobs directly via the job's configuration page if needed. ( see this page).

Building locally

First, checkout EEF projects into your workspace, see this page.

Checkout also the releng projects :

  •  :pserver:dev.eclipse.org:/cvsroot/modeling,org.eclipse.emf/org.eclipse.emf.eef/releng
  •  :pserver:dev.eclipse.org:/cvsroot/technology,org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.dash.common.releng,org.eclipse.dash.common.releng
  •  :pserver:dev.eclipse.org:/cvsroot/eclipse,org.eclipse.releng.basebuilder,org.eclipse.releng.basebuilder,r35x_v20090811

Then, setup the build.properties<code> file in the releng project with correct information for your system:

  • Set all the <code>JAVA*_HOME properties to the location of your JDK install (eg: /usr/lib/jvm/java-1.6.0-openjdk or C:/Program Files/Java/jdk1.6.0_16)
  • Set the WORKSPACE property to a writable directory (eg: /tmp or C:/temp)
  • change the dependencyURLs with the Eclipse SDK zip specific to your platform

Additionally, you should change all the dependencyURLs to point to one of your local Eclipse mirrors, to avoid saturating the main Eclipse download server, and getting extremely slow downloads.

Alternatively, you can download the dependencies manually and put them in your downloadsDir. The build will then use the files you provided instead of downloading them itself.

Finally, start the build by right-clicking the build.xml file in the releng project inside Eclipse and choosing Run as > Ant Build.

Retention Policy

Code in CVS

Any code that was included in a Release, is left in CVS forever. For all major version, a branch is created with a convenient name, like "0_8_BRANCH". The maps files are the definitive authority on what was included in a release.

Distributions in zip files

Formal releases are kept forever, but only the most recent release is kept on the main download page ( see installation guide. Other, older distributions can be found on the archive site.

While developing a new releases, ALL milestone builds are kept until the release, at which point they are deleted.

Similarly, while developing a milestone, weekly integration builds are kept until the milestone is available, and then they are deleted.

Finally, while developing an integration build, nightly are kept until the integration is available, and then they are deleted.

Features in update site repository

Only the most recent release (and/or patches) are kept on the update site. The goal is to allow users to update to the latest code from what they have installed, but we don't support updating to some previous release. For example, if we come out with a "3.0.3", the "3.0.2" version won't be on the update site any longer. So, someone with "3.0.0" installed could update to "3.0.3", but they could no longer update only to "3.0.2", once 3.0.3 was released.

see installation guide for the list of available update sites.

The update site repository will be treated as a persistent repository of content. (From WTP 3.1.1, onward.) Once s