Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/Papyrus Developer Guide/Release Process: How To"

(→‎What is built?)
Line 23: Line 23:
 
== What is built? ==
 
== What is built? ==
  
−
Taking the example of "papyrus-Master", one feature is built:
+
Taking the example of "papyrus-Master", we use the releng's pom.xml file:
−
* org.eclipse.papyrus.build.feature
+
* top-pom-main.xml
  
−
It is referenced as a root dependency in <code>buckminster.cspec</code>.
+
This pom must include all features, plugins and update sites that must be built, either directly or indirectly.
  
−
This feature must include all other features that must be built, either directly or indirectly.
+
The pom.xml file also specifies how to get the plug-ins and features that are to be built.The pom.xml also specifies the update sites from which to retrieve the binary dependencies from the dependent projects.
  
−
The releng project contains a Buckminster rmap, which specifies how to get the plug-ins and features that are to be built. For each plug-in or feature, the map defines its location on a version control system (CVS, SVN, Git, etc.).
+
=== Updating the pom.xml ===
−
 
+
The pom.xml reflects the dependencies on the other projects. So, it must be updated at least before each milestone, to make sure that the code that is built works with the latest versions of all the dependencies.
−
The rmap also specifies the update sites from which to retrieve the binary dependencies from the dependent projects.
+
−
 
+
−
=== Updating the rmap ===
+
−
The rmap reflects the dependencies on the other projects. So, it must be updated at least before each milestone, to make sure that the code that is built works with the latest versions of all the dependencies.
+
  
 
The easiest way to update the dependencies is to copy them from the aggregation build model, which all projects must fill in with the correct reference to their update site(s) and feature(s).
 
The easiest way to update the dependencies is to copy them from the aggregation build model, which all projects must fill in with the correct reference to their update site(s) and feature(s).
  
−
This model is in a project with the release name on the Eclipse CVS:
+
This model is in a project with the release name on the Eclipse Git:
−
* [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.juno.build/?root=Callisto "org.eclipse.<releaseName>.build"] on <code>dev.eclipse.org:/cvsroot/callisto</code>, where releaseName is helios or indigo or juno etc. depending on the version being built.
+
* git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git
  
 
There is a tool that copies most of the information automatically in this plug-in:
 
There is a tool that copies most of the information automatically in this plug-in:
−
* http://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.facet/trunk/releng/org.eclipse.emf.facet.releng.tools (see the [http://dev.eclipse.org/svnroot/modeling/org.eclipse.emft.facet/trunk/releng/org.eclipse.emf.facet.releng.tools/README.TXT README.TXT])
+
* (see the [https://hudson.eclipse.org/papyrus/view/Mars/job/Papyrus-Master-Developer/lastSuccessfulBuild/artifact/releng/dev/target/repository/ Papyrus developer tools])
  
−
'''Warning''': don't forget to update the aggregation model project before copying information from it
+
'''Warning''': don't forget to pull the last changes in order to build the correct state and verify that the branch built is the correct one (master or <Eclipse version>_maintenance, e.g. Luna_maintenance)
  
 
A few dependencies are not in the aggregation build model though, so they must be updated manually:
 
A few dependencies are not in the aggregation build model though, so they must be updated manually:

Revision as of 07:36, 20 May 2015

The Papyrus project is built using Buckminster, with this releng project: http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/releng/org.eclipse.mdt.papyrus.releng.buckminster (only for the trunk; the branches are built with the corresponding project from the branch).

This project contains sub-folders containing the Buckminster configuration for each Hudson job.

Hudson Jobs

The Papyrus builds are started from Hudson. The following jobs on the Mars branch exist currently: There should always be the following jobs on each created branches:

  • papyrus-Master : builds the main plug-ins of Papyrus
  • papyrus-Master-Analysis : static analysis of the code, i.e. findBugs, sonar...
  • papyrus-Master-Tests : builds the tests for the main plugins of Papyrus
  • papyrus-Master-Tests-Failures : tests indentified as failed, not regressions, kept to keep the main tests clean and without spams
  • papyrus-Master-Developer : developer tools, such as debug views in eclipse, papyrus diagram code generator and building tools
  • papyrus-Master-Extra : builds the "extra" plug-ins of Papyrus
  • papyrus-Master-Extra-Tests : builds the tests for the "extra" plug-ins
  • publishTestFramework :

See all the currently defined Papyrus jobs on this page : https://hudson.eclipse.org/papyrus/view/ You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...

What is built?

Taking the example of "papyrus-Master", we use the releng's pom.xml file:

  • top-pom-main.xml

This pom must include all features, plugins and update sites that must be built, either directly or indirectly.

The pom.xml file also specifies how to get the plug-ins and features that are to be built.The pom.xml also specifies the update sites from which to retrieve the binary dependencies from the dependent projects.

Updating the pom.xml

The pom.xml reflects the dependencies on the other projects. So, it must be updated at least before each milestone, to make sure that the code that is built works with the latest versions of all the dependencies.

The easiest way to update the dependencies is to copy them from the aggregation build model, which all projects must fill in with the correct reference to their update site(s) and feature(s).

This model is in a project with the release name on the Eclipse Git:

There is a tool that copies most of the information automatically in this plug-in:

Warning: don't forget to pull the last changes in order to build the correct state and verify that the branch built is the correct one (master or <Eclipse version>_maintenance, e.g. Luna_maintenance)

A few dependencies are not in the aggregation build model though, so they must be updated manually:

Finding dependencies

If you don't know where a particular plug-in or feature is located, the easiest way to find it is to search the Eclipse download area using "find" on build.eclipse.org. For example, to look for "org.eclipse.emf.compare" : 

find /home/data/httpd/download.eclipse.org/modeling/emf/ -name 'org.eclipse.emf.compare_*'

How to start a build?

Automatically

  • Nightly builds are run automatically every night at 00:43 every day.

Manually

Only committers in the Papyrus project can launch Papyrus build jobs from Hudson.

Go to one of these pages, depending on the build you want to launch:

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 builds are automatically published to download.eclipse.org by a cron job that runs on build.eclipse.org. For example, a papyrus-trunk-nightly build for version 0.9.0, created on April 21 2011 at 04:13 would be published to:

These builds can then be seen and downloaded from http://www.eclipse.org/modeling/mdt/papyrus/downloads/, where additional information is available (test results, build log), or installed from the update sites:

With the script

To publish a milestone or release from a trunk build, you can use the manualPromote.sh script on: /opt/public/modeling/mdt/papyrus/manualPromote.sh Start this script, and fill in the parameters in the interactive script. For example: 

$ cd /opt/public/modeling/mdt/papyrus/
$ ./manualPromote.sh
-------------------- user parameters --------------------
mainBuildNumber (the number of the "papyrus-trunk-nightly" Hudson build from which to publish the main Papyrus plug-ins):
? 519
extrasBuildNumber (the number of the "papyrus-trunk-extra-nightly" Hudson build from which to publish the extra Papyrus plug-ins, or 0 to not publish):
? 43
testsBuildNumber (the number of the "papyrus-trunk-nightly-tests" Hudson build from which to publish the test results, or 0 to not publish):
? 93
version (e.g. "0.9.0"):
? 0.9.0
updateSite (e.g. "nightly/juno", "milestones/0.9/M5", "releases/indigo/0.8.1") :
? milestones/0.9/M5
Are you sure you want to publish with these parameters (yes|no)?
? yes

In the previous example, the script will:

  • publish the main Papyrus plug-ins from papyrus-trunk-nightly build #519 to the Papyrus download in "drops/0.9.0" and the update site in "milestones/0.9/M5/main"
  • publish the extra plug-ins from papyrus-trunk-extra-nightly build #43 to the Papyrus download in "drops/0.9.0" in the same build folder as the main build, and the update site in "milestones/0.9/M5/extra"
  • publish the test results from papyrus-trunk-nightly-tests build #93 to the Papyrus download in "drops/0.9.0" in the same build folder as the main build
  • make "milestones/0.9/M5" a composite update site, which contains "milestones/0.9/M5/main" and "milestones/0.9/M5/extra"
  • enable p2 download statistics both on "milestones/0.9/M5/main" and "milestones/0.9/M5/extra"
  • set the correct linux access rights on the new folders

Once the script is done, all you have left to do is to:

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 or scp for example):
wget https://hudson.eclipse.org/hudson/job/papyrus-trunk-nightly/lastSuccessfulBuild/artifact/S201103151256.zip

or, if https access doesn't work, a NFS access can be used (from build.eclipse.org). For example: 

cp /shared/jobs/papyrus-trunk-nightly/lastSuccessful/archive/S201103151256.zip .
  • Then, test the build locally
  • Then, publish it:
ssh <commiterid>@build.eclipse.org
wget https://hudson.eclipse.org/hudson/job/papyrus-trunk-nightly/lastSuccessfulBuild/artifact/S201103151256.zip
unzip S201103151256.zip -d /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/downloads/drops/0.1.0/

Add a new update site with the new build to the composite:

  • unzip the content (the update site zip that was in the first zip) in a new folder with the release number:
unzip Papyrus-Update-0.1.0M6.zip -d /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.1/M6
  • update both the compositeContent.xml and compositeArtifacts.xml files of the update site (that are located in the parent of the folder to which you extracted the update site) to add a reference to your newly added update site
    • set the value of p2.timestamp to the result of "date +%s000"
    • increase the "size" attribute of the children element
    • add a "child" element inside the "children" element with a "location" set to the name of the folder (e.g "M6")
  • You can enable download stats on the repository by running /opt/public/modeling/mdt/papyrus/addDownloadStats.sh on the update site
  • Check that the new build appears on http://www.eclipse.org/modeling/mdt/papyrus/downloads/.
  • Builds can be hidden from this page before a release by modifying downloads-scripts.php in www/modeling/mdt/papyrus/downloads/ on :pserver:anonymous@dev.eclipse.org:/cvsroot/org.eclipse
  • Tag the build

Simultaneous Release

If the build must be part of the simultaneous release, you must also:

Usually, the only thing to change is the location (for example "milestones/0.9/M5/main"): 

<repositories location="http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.9/M5/main" description="Papyrus">

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_TARGET :
    • test : build Papyrus, create the update site, and launch the JUnit tests on the result
    • site.p2 : Launch the build of Papyrus only - no tests
    • provision : Gets only the material required to launch the build
  • BUILD_ALIAS : the name of the release (0.8.0, 0.9.0M1, etc.); leave it blank for nightly and integration builds
  • SIGN_UPDATE_SITE : whether to sign the update site (can take up to an hour on the Eclipse build server); mandatory for all builds except nightlies
  • VERSION : the version being built. Dictates in which folder the build will be placed under the download "drops" folder.

Tagging

Releases should have a tag like 0.9.0, and milestones should have a tag like 0.9.0_M7.

Checking

You can execute the following Bash snippets to check the compliance of different aspects.

Check 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

Check licenses

md5 is useful to see quickly which files differ: 

find $workspaceRoot -type f -name 'license.html' | while read i; do md5 $i; done

Check Manifest.MF

find $workspaceRoot -name 'MANIFEST.MF' | while read i; do grep -q Bundle-Vendor "$i" || echo "$i"; done
find $workspaceRoot -name 'feature.xml' | while read i; do grep -q provider-name "$i" || echo "$i"; done

Check simrel reports

for url in \
   "http://build.eclipse.org/juno/simrel/reports/layoutCheck.txt" \
   "http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt" \
   "http://build.eclipse.org/juno/simrel/reports/versionPatternCheck.txt" \
   "http://build.eclipse.org/juno/simrel/reports/breedata.txt" \
   "http://build.eclipse.org/juno/simrel/reports/pack200data.txt" \
   "http://build.eclipse.org/juno/simrel/reports/nonUniqueVersions.txt"
do
  echo "checking $url"
  curl -s -S "$url" | egrep 'papyrus'
done

url="http://build.eclipse.org/juno/simrel/reports/licenseConsistency.html"
echo "checking $url"
curl -s -S $url > licenseConsistency
n=$(cat licenseConsistency | grep -n "Features with matching" | sed 's/:.*//')
cat licenseConsistency | head -n $n | egrep 'papyrus'

url="http://build.eclipse.org/juno/simrel/reports/featureNames.html"
echo "checking $url"
curl -s -S $url > featureNames
n=$(cat featureNames | grep -n "Probably correct names" | sed 's/:.*//')
cat featureNames | head -n $n | egrep 'papyrus'

url="http://build.eclipse.org/juno/simrel/reports/bundleNames.html"
echo "checking $url"
curl -s -S $url > bundleNames
n=$(cat bundleNames | grep -n "Probably correct bundle name" | sed 's/:.*//')
cat bundleNames | head -n $n | egrep 'papyrus'

url="http://build.eclipse.org/juno/simrel/reports/providerNames.html"
echo "checking $url"
curl -s -S $url > providerNames
n=$(cat providerNames | grep -n "Probably using correct provider name" | sed 's/:.*//')
cat providerNames | head -n $n | egrep 'papyrus'

url="http://build.eclipse.org/juno/simrel/reports/copyrights.html"
echo "checking $url"
curl -s -S $url > copyrights
n=$(cat copyrights | grep -n "Features with copyrights that are probably ok" | sed 's/:.*//')
cat copyrights | head -n $n | egrep 'papyrus'

url="http://build.eclipse.org/juno/simrel/reports/esdata.txt"
echo "checking $url"
curl -s -S $url > esdata
n=$(cat esdata | grep -n "Bundles without an Eclipse-SourceReference" | sed 's/:.*//')
cat esdata | tail -n +$n | egrep 'papyrus'
Retrieved from "https://wiki.eclipse.org/index.php?title=Papyrus/Papyrus_Developer_Guide/Release_Process:_How_To&oldid=384267"

Back to the top