- 1 EEF Releng HOW TO
- 2 Retention Policy
EEF Releng HOW TO
How to start a build?
- Nightly builds are run every 6 hours everyday, at 03:41, 09:41, 15:41 and 21:41 EST, monitoring every change in CVS.
- Only committers in the EEF project can launch build jobs from Hudson. ( do not forget to login )
- 0.8 build [Athena] : go to the 0.8.x job
- 0.9 build [buckminster] : go to the 0.9.x job
- 1.0 build [buckminster] : go to the 1.0.x job
- 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 test a build?
you can test the latest successful build directly on hudson using the update site URL below :
- 1.0 build : https://hudson.eclipse.org/hudson/job/emf-eef-1.0/ws/EEF.p2.repository/
- 0.9 build : https://hudson.eclipse.org/hudson/job/emf-eef-0.9/ws/EEF.p2.repository/
Use with caution, the contents can be totally untested.
How to publish a build?
All successful builds are automatically published to download.eclipse.org once a day. These promote actions are done by a cron job on the build server :
# daily 1.0 EEF builds 3 17 * * * ant -f /shared/jobs/emf-eef-1.0/lastSuccessful/archive/publishroot/publisher.ant -verbose > cronLog-1.0.txt # daily 0.9 EEF builds 5 22 * * * ant -f /shared/jobs/emf-eef-0.9/lastSuccessful/archive/publishroot/publisher.ant -verbose > cronLog-0.9.txt # weekly 0.8 EEF builds 12 19 * * 2 bash /shared/jobs/emf-eef-integration/workspace/org.eclipse.emf/org.eclipse.emf.eef/releng/bash-promote-I.sh
The called scripts 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 EEF 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.
you can manually publish a successful build, a Release build for example. After testing, ssh to build.eclipse.org with commiter id and password and use the above script depending on with build you want to promote.
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.0M2to 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
HEADto 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).
First, checkout EEF projects into your workspace, see this page.
Checkout also the releng projects :
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:
- Set the
WORKSPACEproperty to a writable directory (eg:
- change the
dependencyURLswith 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.
Code in SCM
Any code that was included in a Release, is left in SCM forever. For all major version, a branch is created with a convenient name, like "0_8_BRANCH". For each Released version, a tag is created with convenient name, like "0_8_0_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
EEF provides only p2 repository.
Like distribution in zip files, all releases are kept forever on update sites. For each release, there will be a composite repository that aggregates all the releases for a major version.
While developing a new releases, ALL milestone updates sites are kept until the release, at which point they are deleted.
Similarly, while developing a milestone, weekly integration updates sites are kept until the milestone is available, and then they are deleted.
Finally, while developing an integration updates sites, nightly are kept until the integration is available, and then they are deleted.
see installation guide for the list of available update sites.