- OLDER INFORMATION ***
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.
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
|every day||22:00 EST||Daily|
Submitting For the Build
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.
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
We run our builds on build.eclipse.org (an x86_64 linux machine) with a local userid, e4Build.
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.
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:
We have a set of variables that are needed in order to make the system go.
The base directory that contains all build related files except the JREs.
The branch to check out the releng project (this contains subprojects that contain all our repository to branch mapping). Default is master.
Build architecture, currently x86 or ppc.
Build date in the format YYYYMMDD, ex: 20090625
Build time in the 24 hour clock format HHMM, ex: 1930
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.
The java that is used to launch JVMs from the masterBuild.sh script.
The date and time together: 20090625-1930
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 )