Skip to main content
Jump to: navigation, search

Difference between revisions of "E4/Builds"

< E4
(Milestone Builds)
(Builds)
 
(40 intermediate revisions by 6 users not shown)
Line 1: Line 1:
= Builds =
 
  
== Milestone Builds ==
 
  
<table border="1">
+
*** OLDER INFORMATION ***
<tr>
+
<th>Date</th>
+
<th>Build</th>
+
</tr>
+
  
<tr>
 
<td>Tuesday, 08:30 EDT</td>
 
<td>M3 Candidate</td>
 
</tr>
 
  
<tr>
 
<td>Tuesday, 19:30 EDT</td>
 
<td>M3 Candidate</td>
 
</tr>
 
  
<tr>
+
= Builds  =
<td>Wednesday, 08:30 EDT</td>
+
<td>M3 Candidate</td>
+
</tr>
+
  
<tr>
+
In e4 (like in the other projects under the Eclipse top-level project), we produce regular builds. One important kind of build is called ''integration build'' - usually run once a week to produce a version that is good enough to for purposes of integrating with other teams' work, and for self-hosting. Integration builds simply take what's in master, tag it, and generate a report of changes since the last build.
<td>Wednesday, 19:30 EDT</td>
+
<td>M3 Candidate</td>
+
</tr>
+
  
<tr>
+
== Plug-in Versioning  ==
<td>Thursday, 08:30 EDT</td>
+
<td>M3 Candidate</td>
+
</tr>
+
  
<tr>
+
Our current stable build, [http://download.eclipse.org/e4/downloads/drops/S-0.15-201401152200/index.html e4 0.15], has all of our plugins marked as (Incubation) and new plugins should have a version 0.15.0.qualifier.
<td>Thursday, 19:30 EDT</td>
+
<td>M3 Candidate</td>
+
</tr>
+
  
 +
Now that master is open for our 0.16 stable stream we are following the standard [[Version Numbering]] guidelines. For example, for existing bundles:
  
<tr>
+
*if you contribute bug fixes for a bundle, please increment the number to '''0.11.1.qualifier'''  
<td>Friday, 08:30 EDT</td>
+
*if you change the public API or public classes (to add new API or to refactor API for the 0.16 release), please increment the number to '''0.12.0.qualifier'''
<td>Final build towards M3 - we'll need a go on this build</td>
+
</tr>
+
  
</table>
+
For new bundles, please mark them as '''0.16.0.qualifier'''
  
== Integration Builds ==
+
== Integration Builds ==
  
 
{| border="1"
 
{| border="1"
|+ E4 Integration Builds
+
|+ E4 Integration Builds  
 
|- align="left"
 
|- align="left"
! Date !! Time !! Frequency
+
! Date  
 +
! Time  
 +
! Frequency
 
|-
 
|-
| Thursdays
+
| every day
| 19:30 EST
+
| 22:00 EST  
| Weekly
+
| Daily
 
|}
 
|}
  
 
[http://download.eclipse.org/e4/downloads/ e4 Downloads Page]
 
[http://download.eclipse.org/e4/downloads/ e4 Downloads Page]
  
== Submitting For the Build ==
+
== Submitting For the Build ==
  
In General:
+
In General:  
  
'''Checking in code''': The checkin comment should at a minimum include "bug #", and preferably be of the form "bug # summary"
+
'''Checking in code''': The checkin comment should at a minimum include "bug #", and preferably be of the form "bug # summary"  
  
For the build:
+
For the build:  
  
'''Tool''': Teams should use the "Eclipse Releng Tools" to update their releng project for each build.  The releng tools can be installed from the update sites already included in 3.5.
+
'''Tool''': we don't need to use the releng tool to submit for builds, that happens automatically.
  
[[Image:Install-Releng-Tools.png]]
+
[[Image:Install-Releng-Tools.png]]  
  
'''Tags''': tags should be of the form v<date>, so v20081120 or v20081120-1300
+
Releng tools are in the eclipse updates site now that Luna is released and can be installed from the director app as well:
  
'''Procedure''':
+
eclipse/eclipse -application org.eclipse.equinox.p2.director \
<ol>
+
-consoleLog -noSplash \
<li>check out your team releng project from e4/releng</li>
+
  -repository http://download.eclipse.org/eclipse/updates/4.4 \
<li>use the psf files to check out your core plugins, tests, and examples</li>
+
  -installIU org.eclipse.releng.tools.feature.group
<li>Run Team>Release from the context menu:</li>
+
<ol>
+
<li>Select your team's releng project, like '''org.eclipse.e4.ui.releng'''.<br />
+
[[Image:Release-1.png]]
+
<br />
+
</li>
+
<li>Select the projects you want to release from your map file. <br />
+
[[Image:Release-2.png]]
+
<br />
+
</li>
+
<li>You can review the changed projects in this pane. Make sure 'Generate Build Notes' is selected. <br />
+
[[Image:Release-3.png]]
+
<br />
+
</li>
+
<li>Copy out the build note changes so you can send an email to ''e4-dev@eclipse.org'',
+
with a subject that starts with [releng].  You don not have to select a build
+
notes file to continue. <br />
+
[[Image:Release-4.png]]
+
<br />
+
</li>
+
<li>Enter the release tag for you build. This would normally be the build time and date with a v in front, '''v20090101-1930''' <br />
+
  [[Image:Release-5.png]]
+
<br />
+
</li>
+
<li>You can review the changes to your map file here, or simply continue. <br />
+
[[Image:Release-6.png]]
+
<br />
+
</li>
+
<li>Commit the changes so they will be picked up by the I-build</li>
+
</ol>
+
</ol>
+
  
  
 +
'''Tags''': tags should be of the form v&lt;date&gt;, so v20081120 or v20081120-1300
  
'''Versioning Plugins''': Teams should try and follow the standard versioning rules posted at [[Version_Numbering]]. If you need to copy over an existing eclipse project to make changes, please increment the minor number by 100. i.e. 3.5.0 becomes 3.105.0. When you need to break API, then update the major number. i.e. 3.105.0 becomes 4.0.0
+
'''Versioning Plugins''': Teams should try and follow the standard versioning rules posted at [[Version Numbering]]. If you need to copy over an existing eclipse project to make changes, please increment the minor number by 100. i.e. 3.5.0 becomes 3.105.0. When you need to break API, then update the major number. i.e. 3.105.0 becomes 4.0.0
  
== Build Infrastructure ==
+
== Build Infrastructure ==
  
We run our builds on build.eclipse.org with a local userid, '''e4Build'''.
+
We run our builds on build.eclipse.org (an x86_64 linux machine) with a local userid, '''e4Build'''.  
  
The builds run and publish tests results.
+
=== Build Scripts  ===
  
=== Build Scripts ===
+
The main build project is in <code>e4/releng/org.eclipse.e4.builder</code>. It contains the <code>masterBuild.sh</code> script that can be modified to run a test build or a real build (tagged and uploaded to download.eclipse.org)Our build is now controlled by maven/tycho and the pom.xml.
The main build project is in e4/releng/org.eclipse.e4.builder. We use 2 main bash scripts for building.  '''start.sh''' will build a feature and generate repo data if necessary. '''runBuild.sh''' controls the buildIt checks out the eclipse basebuilder and the e4 builder project. It requests the building of all of the e4 features, and starts the testing, and publishes the results to http://download.eclipse.org/e4/downloads/
+
  
'''start.sh''' runs the PDE builder using org.eclipse.e4.builder/builder/general as the ${builder} property, and builds the different  features requested by '''runBuild.sh'''.
+
It also contains the old PDE build directory, <code>e4/releng/org.eclipse.e4.builder/builder/general</code>, that used to build our master feature.
  
=== Machine Setup ===
+
<br>
  
There are a number of directories that need to be available to run a build.
+
=== Machine Setup  ===
  
<ul>
+
To run the tests, we need a virtual X server on&nbsp;:8:
<li>/opt/public/common: the java installs can be appropriate for your architecture.
+
<pre>
+
apache-ant-1.7.0/        ibm-java2-ppc-50@      ibm-java-jdk-ppc-60@
+
flex_sdk_3.2.0.3794_mpl/  ibm-java2-ppc-50-old@  ibm-java-ppc-60@
+
ibm-java2-142@            ibm-java2-ppc64-50@
+
</pre></li>
+
<li>/shared/eclipse/e4/flex_sdk_3.2.0.3794_mpl</li>
+
<li>/shared/eclipse/e4/build/e4</li>
+
</ul>
+
  
To run the tests, we need a virtual X server on :8:
+
Xvfb&nbsp;:8 -screen 0 1280x1024x24 -auth auth.cfg
 +
metacity --display=:8.0 --replace --sm-disable
  
Xvfb :8 -screen 0 1280x1024x24 -auth auth.cfg
+
Where auth.cfg contains at least:  
 
+
Where auth.cfg contains at least:
+
  
 
  localhost
 
  localhost
  
  
=== TODO ===
+
=== Setup  ===
  
*sign the build.
+
In [http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/tree/org.eclipse.e4.builder/scripts/buildCBI.sh buildCBI.sh]
*generate a zip with 2 projects,  org.eclipse.swt.e4 and org.eclispe.swt.e4.jcl, that can be imported into a workspace in an eclipse with the ActionScript tools installed.
+
*Work with the [[Common_Build_Infrastructure]] to host our builds.
+
*Teams need to generate source features
+
*Update the build email to include
+
**did the tests pass or fail, and
+
**for a compile error, where should people look
+
  
= CVS =
+
We have a set of variables that are needed in order to make the system go.
  
The resources, ui, and swt teams now have plugins in their team area in the e4 project. Our project is under :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
+
{| border="1"
 +
|-
 +
! Variable
 +
! Comments
 +
|-
 +
| writableBuildRoot
 +
|
 +
The base directory that contains all build related files except the JREs.
  
 +
|-
 +
| relengBranch
 +
|
 +
The branch to check out the releng project (this contains subprojects that contain all our repository to branch mapping). Default is master.
  
== Resources ==
+
|-
 +
| arch
 +
|
 +
Build architecture, currently x86 or ppc.
  
The resources CVS structure is:
+
|-
 +
| builddate
 +
|
 +
Build date in the format YYYYMMDD, ex: 20090625
  
*e4
+
|-
**org.eclipse.e4.resources
+
| buildtime
***bundles
+
|
***doc
+
Build time in the 24 hour clock format HHMM, ex: 1930
***examples
+
***features
+
***tests
+
**releng
+
***org.eclipse.e4.resources.releng
+
  
The '''org.eclipse.e4.resources.releng''' contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
+
|-
 +
| eclipseIBuild
 +
|
 +
The ID of the eclipse build we use as a target platform. With the changes to use a zipped repo for the eclipse SDK, this ID is only used to generate URLs on the download page. It should potentially be used to collect the correct p2 repo for the eclipse/equinox SDK.
  
Resources currently has 4 features.  2 feature patches for the plugins (one for rcp, one for platform), a feature that contains the 2 patches, and a test feature for the tests.
+
|-
 +
| javaHome
 +
|
 +
The java that is used to launch JVMs from the masterBuild.sh script.
  
=== Setup/Restrictions ===
+
|-
 +
| buildTimestamp
 +
|
 +
The date and time together: 20090625-1930
  
Resources can currently update a 3.5 SDK I build and run.
 
  
== UI ==
+
|-
 
+
| writableBuildRoot
The UI CVS structure is:
+
|
 
+
|}
*e4
+
**org.eclipse.e4.ui
+
***bundles
+
***doc
+
***examples
+
***features
+
***tests
+
**releng
+
***org.eclipse.e4.ui.releng
+
 
+
The '''org.eclipse.e4.ui.releng''' contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
+
 
+
UI currently has one main feature for the modelled workbench and one feature for the demos.  The build master feature, org.eclipse.e4.master, is also in UI for now.
+
 
+
=== Setup/Restrictions ===
+
 
+
UI currently requires EMF 2.4.1 or 2.5.0 in installed on 3.5 in order to run.  They can be installed from the update site included with the I builds.
+
 
+
== SWT ==
+
 
+
The SWT CVS structure is:
+
 
+
*e4
+
**org.eclipse.e4.swt
+
***bundles
+
***doc
+
***examples
+
***features
+
***tests
+
**releng
+
***org.eclipse.e4.swt.releng
+
 
+
The '''org.eclipse.e4.swt.releng''' contains the map files for building as well as Team Project Sets that should be used for checking out the projects to be worked on.
+
 
+
SWT has 2 features, one for the ActionScript tools and another for the ActionScript tests.
+
 
+
=== Setup/Restrictions ===
+
 
+
To update to the ActionScript tools you must first download and install the Open Source Flex SDK.
+
 
+
'''Setup Flex environment:'''
+
 
+
# Download and install the Adobe Open Source Flex SDK (available from http://opensource.adobe.com). NOTE: The path where you install the Flex SDK must contain no spaces. This is due to a bug in FCSH.
+
# update your eclipse.ini file and add another line at the end, -Dflex.sdk=&lt;your path to the installed sdk&gt;
+
  
Then you can update to the ActionScript tools.  To work on the tools themselves, you must also set the FLEX_SDK classpath variable in Window>Preferences>Java>Build Path>Classpath Variables to point to the sdk location.
+
== Hudson Builds ==
  
 +
Some jobs were setup on Hudson HIPP instance at http://hudson.eclipse.org/e4 .
  
To work on org.eclipse.swt, org.eclipse.swt.e4.jcl, org.eclipse.swt.e4.examples, and org.eclipse.swt.examples you need to create a Linked Resource variable, WORKSPACE, that points to your current workspace root, from Window>Preferences>General>Workspace>Linked Resources. Also if .classpath_flex exists it must be copied to the .classpath entry.
+
For an active repo, I believe we should have 3 jobs:
 +
* <repoName> which builds the latest commit from master (checked hourly) and publish the output to http://download.eclipse.org/e4/snapshots/<repoName>
 +
* <repoName>-Gerrit which builds incoming Gerrit patches to vote +1 or -1 on them
 +
* <repoName>-Sonar which builds latest commit from master (checked weekly) and publish quality reports on SonarQube ( http://dev.eclipse.org/sonar )

Latest revision as of 11:36, 19 February 2015


      • OLDER INFORMATION ***


Builds

In e4 (like in the other projects under the Eclipse top-level project), we produce regular builds. One important kind of build is called integration build - usually run once a week to produce a version that is good enough to for purposes of integrating with other teams' work, and for self-hosting. Integration builds simply take what's in master, tag it, and generate a report of changes since the last build.

Plug-in Versioning

Our current stable build, e4 0.15, has all of our plugins marked as (Incubation) and new plugins should have a version 0.15.0.qualifier.

Now that master is open for our 0.16 stable stream we are following the standard Version Numbering guidelines. For example, for existing bundles:

  • if you contribute bug fixes for a bundle, please increment the number to 0.11.1.qualifier
  • if you change the public API or public classes (to add new API or to refactor API for the 0.16 release), please increment the number to 0.12.0.qualifier

For new bundles, please mark them as 0.16.0.qualifier

Integration Builds

E4 Integration Builds
Date Time Frequency
every day 22:00 EST Daily

e4 Downloads Page

Submitting For the Build

In General:

Checking in code: The checkin comment should at a minimum include "bug #", and preferably be of the form "bug # summary"

For the build:

Tool: we don't need to use the releng tool to submit for builds, that happens automatically.

Install-Releng-Tools.png

Releng tools are in the eclipse updates site now that Luna is released and can be installed from the director app as well:

eclipse/eclipse -application org.eclipse.equinox.p2.director \
-consoleLog -noSplash \
-repository http://download.eclipse.org/eclipse/updates/4.4 \
-installIU org.eclipse.releng.tools.feature.group


Tags: tags should be of the form v<date>, so v20081120 or v20081120-1300

Versioning Plugins: Teams should try and follow the standard versioning rules posted at Version Numbering. If you need to copy over an existing eclipse project to make changes, please increment the minor number by 100. i.e. 3.5.0 becomes 3.105.0. When you need to break API, then update the major number. i.e. 3.105.0 becomes 4.0.0

Build Infrastructure

We run our builds on build.eclipse.org (an x86_64 linux machine) with a local userid, e4Build.

Build Scripts

The main build project is in e4/releng/org.eclipse.e4.builder. It contains the masterBuild.sh script that can be modified to run a test build or a real build (tagged and uploaded to download.eclipse.org). Our build is now controlled by maven/tycho and the pom.xml.

It also contains the old PDE build directory, e4/releng/org.eclipse.e4.builder/builder/general, that used to build our master feature.


Machine Setup

To run the tests, we need a virtual X server on :8:

Xvfb :8 -screen 0 1280x1024x24 -auth auth.cfg
metacity --display=:8.0 --replace --sm-disable 

Where auth.cfg contains at least:

localhost


Setup

In buildCBI.sh

We have a set of variables that are needed in order to make the system go.

Variable Comments
writableBuildRoot

The base directory that contains all build related files except the JREs.

relengBranch

The branch to check out the releng project (this contains subprojects that contain all our repository to branch mapping). Default is master.

arch

Build architecture, currently x86 or ppc.

builddate

Build date in the format YYYYMMDD, ex: 20090625

buildtime

Build time in the 24 hour clock format HHMM, ex: 1930

eclipseIBuild

The ID of the eclipse build we use as a target platform. With the changes to use a zipped repo for the eclipse SDK, this ID is only used to generate URLs on the download page. It should potentially be used to collect the correct p2 repo for the eclipse/equinox SDK.

javaHome

The java that is used to launch JVMs from the masterBuild.sh script.

buildTimestamp

The date and time together: 20090625-1930


writableBuildRoot

Hudson Builds

Some jobs were setup on Hudson HIPP instance at http://hudson.eclipse.org/e4 .

For an active repo, I believe we should have 3 jobs:

  • <repoName> which builds the latest commit from master (checked hourly) and publish the output to http://download.eclipse.org/e4/snapshots/<repoName>
  • <repoName>-Gerrit which builds incoming Gerrit patches to vote +1 or -1 on them
  • <repoName>-Sonar which builds latest commit from master (checked weekly) and publish quality reports on SonarQube ( http://dev.eclipse.org/sonar )

Back to the top