Jump to: navigation, search

Difference between revisions of "Common Build Infrastructure/Build Types"

 
(2 intermediate revisions by 2 users not shown)
Line 10: Line 10:
  
 
* Integration (I) - run weekly on schedule
 
* Integration (I) - run weekly on schedule
: If you are building from a mapfile, you can have Hudson monitor your releng project for changes and only run a build if the maps change; thus these builds will only run when changes are released from HEAD into the map (eg., using the [http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/download.php?dropFile=org.eclipse.releng.tools-3.5.zip Eclipse Releng Tools plugin] to <code>Team > Release...</code>).  
+
: If you are building from a mapfile, you can have Hudson monitor your releng project for changes and only run a build if the maps change; thus these builds will only run when changes are released from HEAD into the map (eg., using the [http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/download.php?dropFile=org.eclipse.releng.tools-3.5.zip Eclipse Releng Tools plugin] to <code>Team > Release...</code>).
: '''NOTE:''' ''Rather than the manual [http://download.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/download.php?dropFile=org.eclipse.releng.tools-3.5.zip Eclipse Releng Tools plugin], you can also set up a [[Modeling_Project_Releng/Releasing/Scheduled_Releases|crontab script]] to perform an across-the-board check for changes and automatically release them into the map file(s). See [http://dev.eclipse.org/viewcvs/index.cgi/releng-common/tools/org.eclipse.releng.tools.tagandrelease/?root=Modeling_Project this script] for an example of how to do so.''
+
 
: Or, set Hudson to just run a build once a week from HEAD.  
+
{{note|Tagging for Release |Rather than the manual releng tools plugin you can also set up a contab to perform an across-the-board check for changes and automatically release them into the map file(s).}}
 +
 
 +
Or, set Hudson to just run a build once a week from HEAD.  
  
 
* Stable (S) - including Milestones and Release Candidates, these are run every 4-6 weeks at the start of a cycle, then weekly as needed at the end of a cycle.
 
* Stable (S) - including Milestones and Release Candidates, these are run every 4-6 weeks at the start of a cycle, then weekly as needed at the end of a cycle.

Latest revision as of 22:45, 30 October 2009

Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.


Generally, there are 4 types of builds run at Eclipse.

These are:

  • Nightly (N) - run continuously as SVN or CVS changes; generally run from trunk or head.
Continuously really means "will check repository every X minutes and build if required."
See also Snapshot Dependencies
  • Integration (I) - run weekly on schedule
If you are building from a mapfile, you can have Hudson monitor your releng project for changes and only run a build if the maps change; thus these builds will only run when changes are released from HEAD into the map (eg., using the Eclipse Releng Tools plugin to Team > Release...).
Note.png
Tagging for Release
Rather than the manual releng tools plugin you can also set up a contab to perform an across-the-board check for changes and automatically release them into the map file(s).


Or, set Hudson to just run a build once a week from HEAD.

  • Stable (S) - including Milestones and Release Candidates, these are run every 4-6 weeks at the start of a cycle, then weekly as needed at the end of a cycle.
  • Release (R) - once at the end of the cycle.

There is also a 5th type, the Maintenance (M) build, which is essentially a weekly Integration build, but done as maintenance on a branch rather than as integration from trunk or head.

To create these different types of builds, input the following variables into and Athena build / Hudson job:

Nightly

Set the build type to "N", which will disable signing to save time and server resources.

If you want to build from HEAD (or another branch/tag) instead of respecting the values in the map file, use the option below:

BUILDTYPE = N
EXTRAFLAGS = -forceContextQualifier -fetchTag HEAD

Integration or Maintenance

Set build type to "I" or "M", as appropriate.

If you want plugins to all be timestamped with the build's timestamp instead of the unique values from the tags in the map files, set -forceContextQualifier. Generally, this is NOT recommended unless your maps contain "HEAD" or "trunk"

BUILDTYPE = I
EXTRAFLAGS = -forceContextQualifier 

Stable or Release

Set build type to "S" or "R", as appropriate.

Since these builds are stable, they should be built from tags and thus -forceContextQualifier should not be needed.

BUILDTYPE = S
EXTRAFLAGS = -buildAlias 0.2.0M3
 or 
BUILDTYPE = R
EXTRAFLAGS = -buildAlias 0.2.0