Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EMF Facet/Releng/How to Use
The EMF Facet project is built using Buckminster, with this releng project.
EMF Facet uses the same build system as MoDisco. So, for more explanation about how the build process works, see also MoDisco Releng : How it Works.
Contents
What is built?
org.eclipse.emf.facet.all
is the feature that is built (defined in buckminster.cspec).
This feature must include all other features that must be built, either directly or indirectly.
The releng project contains a Buckminster rmap, which specifies how to get the plugins and features that are to be built. For each plugin or feature, the map defines its location on a version control system (CVS, SVN), and the version that must be used.
The rmap also specifies the update sites from which to retrieve the dependencies.
How to start a build?
Automatically
45 2-23/3 * * *
- Nightly builds are run every 3 hours everyday, if the EMF Facet SVN changed since the last build.
- Integration builds are started manually
Manually
- Only committers in the EMF Facet project, and members of the Callisto-dev group can launch EMF Facet build jobs from Hudson.
- Nightly build : go to https://hudson.eclipse.org/hudson/job/emffacet-nightly/
- Integration build : go to https://hudson.eclipse.org/hudson/job/emffacet-integration/
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. For example, a nightly build for version 0.1.0, created on April 21 2011 at 04:13 would be published to:
http://download.eclipse.org/facet/downloads/drops/0.1.0/N201104210413
These builds can then be seen and downloaded from http://www.eclipse.org/modeling/emft/facet/downloads/, where additional information is available (test results, build log).
Manually
Stable, Maintenance and Release builds are not automatically published. They should be first tested internally before publishing. For example, to publish the 0.1.0M6 milestone build:
- First, fetch the build archive to test (from Hudson, or using
wget
orscp
for example):
wget https://hudson.eclipse.org/hudson/job/emffacet-integration/lastSuccessfulBuild/artifact/S201103151256.zip
- Then, test the build locally
- Then, publish it:
ssh <commiterid>@build.eclipse.org wget https://hudson.eclipse.org/hudson/job/emffacet-integration/lastSuccessfulBuild/artifact/S201103151256.zip unzip S201103151256.zip -d /home/data/httpd/download.eclipse.org/facet/downloads/drops/0.1.0/
- Finally, for a milestone, update the update site with the new build:
rm -rf /home/data/httpd/download.eclipse.org/facet/updates/milestones/0.1/* unzip EMFFacet-Update-0.1.0M6.zip -d /home/data/httpd/download.eclipse.org/facet/updates/milestones/0.1
- For a release:
- Create a new folder with the release number under /home/data/httpd/download.eclipse.org/facet/updates/release
- update
compositeContent.xml
andcompositeArtifacts.xml
to add a reference to your newly added release
- TODO: download stats <! --You can enable download stats on the repository by running addDownloadStats.shon the update site -->
- Check that the new build appears on [1].
- Builds can be hidden from this page before a release by modifying
downloads-scripts.php
inwww/modeling/emft/facet/downloads/
on:pserver:anonymous@dev.eclipse.org:/cvsroot/org.eclipse
- Update the archive site with the new build:
- copy the drop folder (eg. "S201103151256") into
/home/data/httpd/archive.eclipse.org/facet/downloads/drops/0.1.0/
- update
/home/data/httpd/archive.eclipse.org/facet/downloads/index.html
with a link to the newly added update zip
- copy the drop folder (eg. "S201103151256") into
- Tag the build
Simultaneous Release
If the build must be part of the simultaneous release, you must also:
- Use the B3 Aggregator (or a text editor if the modification is trivial) to update the build model for the aggregator (after checking it out from CVS).
Build parameters
Hudson builds expect these parameters:
- 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
- BUILD_ALIAS : the name of the release (0.8.0, 0.9.0M1, etc.); blank for nightly and integration builds
- SIGN_UPDATE_SITE : whether to sign the update site (takes about an hour on the Eclipse build server); mandatory for releases
- VERSION : the version being built. Dictates in which folder the build will be placed under the download "drops" folder.
- PROJRELENGROOT : The path on the SVN (trunk, branch or tag) from which to take the version of the releng project that must be used for this build.
Tagging
Releases should have a tag like R0_1_0, and milestones should have a tag like S0_1_0M7.
Checking bundles
Check that each bundle contains an about.html file:
for f in $( ls *.jar ); do unzip -t $f | grep -q about.html || echo $f; done
or for plug-ins in your workspace:
find $workspaceRoot -name 'build.properties' | while read i; do grep -q about.html "$i" || echo "$i"; done