Skip to main content
Jump to: navigation, search

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

(Build parameters)
(D-day of the GA release)
 
(18 intermediate revisions by 2 users not shown)
Line 12: Line 12:
 
== Hudson Jobs ==
 
== Hudson Jobs ==
  
The Papyrus builds are started from Hudson. The following jobs on the [https://hudson.eclipse.org/papyrus/view/Neon%20(Master)/ Neon branch] exist currently.
+
The Papyrus builds are started from Jenkins. The following jobs on the [[https://ci.eclipse.org/papyrus/view/Master/ | Master branch]] exist currently.
 
There should always be the following jobs on each release branch:
 
There should always be the following jobs on each release branch:
 
* papyrus-Master : builds the main plug-ins of Papyrus
 
* papyrus-Master : builds the main plug-ins of Papyrus
Line 19: Line 19:
 
* papyrus-Master-Tests-Failures : tests identified as failed, not regressions, kept to keep the main tests clean and without spams
 
* papyrus-Master-Tests-Failures : tests identified as failed, not regressions, kept to keep the main tests clean and without spams
 
* papyrus-Master-Toolsmiths : developer tools, such as debug views in eclipse, papyrus diagram code generator, building and customization tools
 
* papyrus-Master-Toolsmiths : developer tools, such as debug views in eclipse, papyrus diagram code generator, building and customization tools
 
 
* papyrus-XYZ-Developer : developer tools, such as debug views in eclipse, papyrus diagram code generator  and building tools (Oxygen and previous versions)
 
* papyrus-XYZ-Extra : builds the "extra" plug-ins of Papyrus (Neon and previous versions)
 
* papyrus-XYZ-Extra-Tests : builds the tests for the "extra" plug-ins (Neon and previous versions)
 
 
  
 
See all the currently defined Papyrus jobs on the page :  
 
See all the currently defined Papyrus jobs on the page :  
 
<nowiki>https://hudson.eclipse.org/papyrus/view/<release_name></nowiki>
 
<nowiki>https://hudson.eclipse.org/papyrus/view/<release_name></nowiki>
 
You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...
 
You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...
 +
  
 
== Before starting a build ==
 
== Before starting a build ==
Line 45: Line 40:
 
=== Must Have ===
 
=== Must Have ===
  
As a rule of thumbs, before starting your build journey it is preferable to possess a clean install of the Eclipse you want to test your build against.
+
As a rule of thumbs, before starting your build journey it is preferable to have a clean install of the Eclipse package you want to test your build against and install the necessary tools and dependencies.
Then install the following on it (some may require you to fetch previously build components from other projects that contributes earlier in the train:
+
You will need to install the following (some may require you to fetch previously build components from other projects that contributes earlier in the train):
  
 
Use an Eclipse with Papyrus developer tools installed from the following update site, eg for the XYZ version:  
 
Use an Eclipse with Papyrus developer tools installed from the following update site, eg for the XYZ version:  
Line 54: Line 49:
 
  <nowiki>https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ/lastSuccessfulBuild/artifact/repository/</nowiki>   
 
  <nowiki>https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ/lastSuccessfulBuild/artifact/repository/</nowiki>   
 
Install the tpd updater tool from this [https://github.com/mbarbero/fr.obeo.releng.targetplatform Github project] from this update site:  
 
Install the tpd updater tool from this [https://github.com/mbarbero/fr.obeo.releng.targetplatform Github project] from this update site:  
  <nowiki>https://dl.bintray.com/mbarbero/fr.obeo.releng.targetplatform/latest</nowiki>  
+
  <nowiki>https://dl.bintray.com/mbarbero/fr.obeo.releng.targetplatform/latest</nowiki> (4.1.0 and before)
 +
<nowiki>http://download.eclipse.org/cbi/tpd/**</nowiki> (4.2.0 and after)
  
Papyrus (a clean clone is also useful to have for the builds as it will be much less susceptible to be corrupted by your daily work):
+
Papyrus (a clean clone is also useful to have for the builds as it will be much less susceptible to be corrupted by your daily work) up to date:
 
  <nowiki>git://git.eclipse.org/gitroot/papyrus/org.eclipse.papyrus.git</nowiki>  
 
  <nowiki>git://git.eclipse.org/gitroot/papyrus/org.eclipse.papyrus.git</nowiki>  
 
Simrel on which you will later post your updated aggregator file:
 
Simrel on which you will later post your updated aggregator file:
Line 64: Line 60:
 
  https://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Installation
 
  https://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Installation
  
== Release steps - Mandatory ==
 
  
As mentioned before, the release is orchestrated through the pom.xml files. These files must include all features, plugins and update sites that are necessary for the code to compile, either directly or indirectly.
+
== Update Papyrus Dependencies and References ==
  
The releng's pom.xml files also specifies how to get the plug-ins and features that are to be built and specifies the update sites from which to retrieve the binary dependencies from the dependent projects.
+
You need to [[Papyrus Developer Guide/Release Process: How To/Update Papyrus Dependencies | prepare the content]] for the next release by checking that everything depends on the latest releases of the train and that the versions are all up to date.
  
  
=== Update the target platforms' dependencies ===
+
== Publish The artifacts ==
  
These files reflect the dependencies on other projects. Hence, it must be updated before each milestone, at the very least, to make sure that the code that is built works with the latest versions of all the dependencies.
+
When the produced artifacts are successfully produced by the Jenkins job and that you tested their installation and functionalities you will be able to [[Papyrus Developer Guide/Release Process: How To/Publish Papyrus Artifacts | publish them]].
  
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:
+
=== Checking the reports ===
<nowiki>git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</nowiki>
+
  
[[File:cloneSimrelRepo.png|center|800px|thumb|'''Clone the simrel repository''']]
+
At the end of each milestone you will need to check the installation from the staging update site and check the reports generated by the simrel aggregation job.
  
 +
The simrel reports are available at :
 +
* <nowiki>https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/**BuildNumber**/artifact/target/repository/final/buildInfo/reporeports/index.html</nowiki>
  
[[File:importBuildToolsAfterClone.png|center|600px|thumb|'''Import the simrel project''']]
+
And the simrel/staging update site at :
 
+
 
+
==== First: Verify that the branch is up to date====
+
Verify that the branch is up to date (fetch and rebase or a pull).
+
git fetch origin
+
git rebase origin/master
+
 
+
 
+
[[File:updateRepository.png|center|800px|thumb|'''update the local repository''']]
+
 
+
 
+
Be on the correct branch of the simrel repository before selecting the aggregation model in order to have the correct addresses of the papyrus' version dependencies (master or <release_name>_maintenance, e.g. Luna_maintenance) as the models will differ from one another and result in erroneous updates.
+
 
+
 
+
[[File:simrelBuildModelBranch.png|center|600px|thumb|'''The branches corresponding to the different <release_name>''']]
+
 
+
 
+
[[File:simrelBuildModel.png|center|600px|thumb|'''The simrel model used to update the dependencies''']]
+
 
+
==== Second: Update the Target Platforms ====
+
 
+
Update the target's dependencies adresses to the latest release available.
+
A few dependencies are not in the aggregation build model though, so they must be updated manually (e.g. nebula). To get them check the tpd's '// manualUpdate' tags.
+
find . -name "*.tpd" | xargs grep -a2 -n "manualUpdate" {}
+
 
+
==== Finding manual dependencies update site ====
+
 
+
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 the ssh of build.eclipse.org.
+
For example, using the ssh connection to the eclipse repository, to look for "org.eclipse.emf.compare" :
+
find /home/data/httpd/download.eclipse.org/modeling/emf/ -name 'org.eclipse.emf.compare_*'
+
 
+
 
+
[[File:update_pom_dependencies.png|center|600px|thumb|'''Update the dependencies of the selected poms''']]
+
 
+
 
+
Then verify that both the .tpd and .target have been correctly updated and that the changes are coherent (e.g. with eclipse, Compare with > HEAD revision).
+
 
+
=== Verify the jboss Update sites ===
+
 
+
Some modules will provide the installer with additional update sites if necessary to facilitate the installation for the end user. Those won't be part of the default set of update sites in the IDE and therefore must be maintained.
+
Look into the pom.xml file for the <associateSites> and update them if necessary and/or you updated their references in the targetplatforms.
+
 
+
 
+
=== Update Oomph setup file ===
+
 
+
A good/nice practice is to also update Oomph's papyrus.setup while we are at it. An integrated developer tool is available to do this under the contextual menu "Update dependencies from aggregation build model" (i.e. the simrel aggregation files)
+
 
+
 
+
=== Push the modifications on gerrit ===
+
 
+
There should be a Bug listing all the releng maintenance (e.g. The [https://bugs.eclipse.org/bugs/show_bug.cgi?id=525277 oxygen releng bug]) linking all the commits done.
+
Therefore when pushing to the papyrus' gerrit you should use the standardized message :
+
* Bug XXXXXX [Releng] Update dependencies for <release_name> <Milestone> (e.g.: Bug 525277 [Releng] Update dependencies for Oxygen M7).
+
 
+
Then wait for The build instance to validate the contribution and for a committer to merge the changes.
+
 
+
== Release steps - Optionals ==
+
 
+
==== Updating the versions ====
+
 
+
During a release you can have to update the plugin versions and their linked features and categories as the API and other contents of the plug-in change, in accordance with the [[Version Numbering|Eclipse Versioning Guidelines]].
+
The '''PDE API Tooling''' builders help to identify version number changes that are required by flagging problems on the bundle manifests.  Also, if enabled, the '''Oomph Version Management''' builders perform additional checks, including;
+
 
+
* consistency of POM version number with plug-in/feature manifest
+
* ripple effect of bundle version number changes up to features that include them
+
 
+
Also, be aware that some version number changes also require updates to other metadata, such as the '''category.xml''' and the '''*.product''' definition files for any RCP packages (especially for feature version changes).
+
 
+
As of the Neon release, Papyrus plug-in and feature versions '''are not''' bulk updated to the "next" version number as they were in previous releases.  Accordingly, '''BundleTestUtils.java''' (tests>junit>plugins>developer>org.eclipse.papyrus.bundle.tests) no longer tracks the expected current version number of bundles.  Correct versions are enforced by PDE and Oomph tooling.
+
 
+
 
+
== Builds ==
+
 
+
Builds, master and maintenance, are run automatically every night, every day and each half an hour if there has been a change in the code base. Tests are run twice a day as they take quite a bit of time.
+
When a build following specific changes is required, wait for the gerrit contribution to be merged and launch the main build and then the Tests. Once both are successful launch a signed build for each of them.
+
 
+
'''Note''' that the tests depend on the '''xxx-Toolsmiths''' (previously '''xxx-Developer''' for Oxygen and older versions) build. Therefore don't forget to launch this one before or this might result in an error (in case of a version update for example as the tests will only find the old version).
+
 
+
 
+
=== How to start a build ===
+
 
+
Only committers or release engineers in the Papyrus project can launch Papyrus build jobs from Hudson.
+
 
+
Go to the desired page if you want to launch a selected build (e.g.: The [https://hudson.eclipse.org/papyrus/view/Oxygen/ Oxygen] page).
+
 
+
 
+
[[File:buildParameters.png|center|1000px|thumb|'''Enter the build parameters''']]
+
 
+
 
+
Then:
+
* In Hudson, click on '''Build Now''', change the [[#Build parameters]] as needed, 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.
+
 
+
 
+
=== Build parameters ===
+
 
+
Hudson builds expect these parameters:
+
* BUILD_ALIAS : the name of the release (0.9.0, 1.1.0M6, etc.); leave it blank for nightly and integration builds. As a side note the [https://www.eclipse.org/papyrus/downloads/ downloads area] is configured to only accept Strings formated according to the [http://git.eclipse.org/c/www.eclipse.org/papyrus.git/tree/downloads/index.php index.php] file. E.g. underscores or spaces won't be interpreted.
+
* SIGN : whether to sign the update site (can take up to an hour on the Eclipse build server); '''mandatory''' for all builds except nightlies
+
 
+
 
+
'''Warning''':
+
* Don't forget to do the same manipulation for the Master-Toolsmiths.
+
* Keep both build ids, you will need them for the manual publish
+
* Keep both green jobs artifacts by clicking "Keep this job forever", at least during the release process
+
 
+
'''Tip''': As the signing of the build can take quite a long time, it is recommended to launch a non-signed build first. Then launch the tests against the unsigned build as it already is what will be published. As the tests roughly take the same amount of time you can see if the current build passes the tests without having to wait the extra time needed by the signing step.
+
 
+
== Publish a build ==
+
 
+
Successful Nightly builds are automatically published to :
+
* http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/
+
 
+
 
+
=== Before Publishing ===
+
 
+
Stable builds are not automatically published. They should be first tested internally before publishing.
+
* '''First''', install the build on the update site nightly http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/[release_name]/
+
* '''Then''', test it locally
+
 
+
 
+
=== Publish ===
+
 
+
To publish a milestone or release from a build, you can use the following scripts on: <code>/opt/public/modeling/mdt/papyrus/</code>
+
* manualPromote-[release_name].sh
+
if there are any doubt on which to use, you can always search the repository for the present promote scripts and pick the correct one: <code> ls -la </code>.
+
 
+
Start this script, and fill in the parameters in the interactive script:
+
* the signed builds numbers
+
* the corresponding version
+
* the update site in which to publish it
+
 
+
'''Be careful''' however as Hudson does not make, as of yet, a zip for the tests and the current script will crash if a build number is provided and it does not find any corresponding zip. This may lead to some, fixable but annoying, access permissions problems.
+
 
+
 
+
For example:
+
 
+
[[File:manualPromote-mars.png|center|800px|thumb|'''example''']]
+
 
+
 
+
In the previous example, the script will:
+
* publish the main Papyrus plug-ins from Papyrus-Master build #1600 to the Papyrus download in "drops/1.1.0" and the update site in "milestones/1.1/RC3/main"
+
* publish the extra plug-ins from Papyrus-Master-Extra build #1237 to the Papyrus download in "drops/1.1.0" in the same build folder as the main build, and the update site in "milestones/1.1/RC3/extra"
+
* do not publish the test results from Papyrus-Master-Tests build
+
* make "milestones/1.1/RC3" a composite update site, which contains "milestones/1.1/RC3/main" and "milestones/1.1/RC3/extra"
+
* enable p2 download statistics both on "milestones/1.1/RC3/main" and "milestones/1.1/RC3/extra"
+
* set the correct linux access rights on the new folders
+
 
+
 
+
* '''Check''' that the new build appears on http://www.eclipse.org/papyrus/downloads/.
+
* '''Check''' the edited composites on http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/?d. (or [...]/releases/?d in case of a release)
+
** and add browse through the directory content to check your version, e.g.: /1.1 will give you the edited root composites, and 1.1/M6 will give you the main and extra composites
+
 
+
 
+
Once you have verified that what you have pushed is there, all you have left to do is to:
+
* '''Tag the last commit''': Releases should have a tag like 1.1.0, and milestones like 1.1.0_M6
+
** git tag -a 2.0.1_RC4 -m "Create the tag 2.0.1_RC4" d4c28a3b7c1c46cf5407bbfae2eda602eb4480c7
+
** git push origin 2.0.1_RC4
+
 
+
Add a new update site with the new build to the parent composite (~/downloads/modeling/mdt/papyrus/updates/milestones/1.1/):
+
* '''update''' both the <code>compositeContent.xml</code> and <code>compositeArtifacts.xml</code> 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 "<code>date +%s000</code>"
+
** 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")
+
 
+
 
+
[[File:compositeArtifacts.png|center|1000px|thumb|'''The values to edit''']]
+
 
+
Builds can be hidden from this page before a release by modifying <code>downloads-scripts.php</code> in <code>/downloads/</code> on [git://git.eclipse.org/gitroot/www.eclipse.org/papyrus.git git://git.eclipse.org/gitroot/www.eclipse.org/papyrus.git]
+
 
+
=== Simultaneous Release ===
+
 
+
If the build must be part of the simultaneous release, you must also:
+
* Use the [http://wiki.eclipse.org/Eclipse_b3/aggregator/manual B3 Aggregator] (or a text editor if the modification is trivial) and push to the simrel's gerrit which path is :
+
<nowiki>ssh://username@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git</nowiki>
+
Usually, the only thing to change is the location (for example "milestones/1.1/M6/main"):
+
<repositories location="http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/1.1/M6/main" description="Papyrus">
+
 
+
[[File:UpdatePapyrusContributionToMarsM7.png|center|1300px|thumb|'''Previous composite address''']]
+
 
+
 
+
[[File:UpdatePapyrusContributionToMarsRC1.png|center|1300px|thumb|'''Updated composite address''']]
+
 
+
 
+
'''Tip''': You can check the status of the contribution at [https://git.eclipse.org/r/#/q/status:open+project:simrel/org.eclipse.simrel.build+branch:master simrel's gerrit page]
+
 
+
=== Finalizing the Release ===
+
 
+
When the release is complete and has been tagged in the repository, it is time to prepare the next release's development branch for continued version management.  One aspect of this is ensuring that the Oomph Version Management tool's reference baseline for the next release completely and correctly describes the release just completed.
+
 
+
Oomph maintains a description of the release in the <tt>release.*</tt> files in the Papyrus release bundles in the <tt>plugins/developer</tt> tree.  So far, these are:
+
 
+
* <tt>oep.releng.main.release</tt> for the Papyrus Main product bundles and features
+
* <tt>oep.releng.dev.release</tt> for the Papyrus Developer Tools bundles and features
+
 
+
The <tt>release.xml</tt> file is a manifest of all of the features and bundles, with their versions and the relationships between them, that comprise the Papyrus Release and the <tt>release.digest</tt> is a more efficient binary representation of the same that is loaded by Oomph tooling when needed.  The Oomph Version Management builder creates these automatically from the current workspace and PDE target configuration, so long as all of the Papyrus feature projects are in the workspace.  To rebuild the release description, simply '''delete''' the <tt>release.xml</tt> and <tt>release.digest</tt> files and they will be rebuilt with all of the requisite metadata to describe what is now the "previous release" reference baseline for the next release.
+
 
+
For this process to work you will need Oomph, Papyrus' developer tools installed on your eclipse and all the papyrus' features and plugins that you want to reference imported in your workspace (as a good practice it is preferable to import all of Papyrus so as to update all the references). If you do not, the tool will only be able to access and therefore log the ones present.
+
After deleting the <tt>release.xml</tt> and <tt>release.digest</tt> simply clean and build both projects and both files will be created anew and updated.
+
This step may result in Unresolved tags which in this case might impose you to complete the version numbers by hand if you have no alternative.
+
 
+
 
+
 
+
== Checking ==
+
 
+
=== Check simrel reports ===
+
 
+
After the simrel build, you can check the reports at :
+
* https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html
+
 
+
 
+
=== Check installations ===
+
 
+
Check installation from the simrel/staging update site at :
+
 
* http://download.eclipse.org/releases/staging (Master)
 
* http://download.eclipse.org/releases/staging (Master)
 
* http://download.eclipse.org/releases/maintenance (Maintenance)
 
* http://download.eclipse.org/releases/maintenance (Maintenance)
  
 +
== Preparing the GA release ==
  
==Check list to publish a release for papyrus project leader==
+
When the final artifacts have been contributed and each milestones have been tagged in the repository, it is time to [[Papyrus Developer Guide/Release Process: How To/Prepare the GA Release | prepare the for the GA release]].
  
* update information  for the version to release https://projects.eclipse.org/projects/modeling.mdt.papyrus
 
===IP Log managment===
 
* Verifiy the IP log by generate the IP log on the same page
 
* If needed, create CQ but normaly all CQs could have be done before the review process
 
* Then submit the review
 
* A bug is generated that you '''must''' follow for example https://dev.eclipse.org/ipzilla/show_bug.cgi?id=16458
 
  
===Review process===
+
== D-day of the GA release ==
* Go to the page https://projects.eclipse.org/projects/modeling.mdt.papyrus
+
* Launch the review for the release. when there is review, an eye icon is displayed on the line
+
* A bug is generated that you '''must''' follow for example : https://bugs.eclipse.org/bugs/show_bug.cgi?id=535121
+
  
 +
Keep in mind that depending on the date of your release review, you might have an official release day after the GA of the built Eclipse Package.
  
 
+
When your day comes however (means that your release is review and the Eclipse declare the GA official on the cross-project mailing list), you will have to:
== Official release (post RC4) ==
+
 
+
After you have released all the candidates, there usually is a quiet week when all the projects are to check for breaking or critical bugs. This time can be used, at the earliest, to initiate the final stage of the release plan.
+
 
+
==== Update the RCP and the SDK versions ====
+
Do not forget that you will need to release the RCP corresponding to the release. therefore you should build a new one just after the final RC build and keep the artifacts to publish them the day you do the official release.<br/>
+
Do not forget to create a patch incrementing the SDK features and the RCP product in order to begin anew as soon as possible. (i.e. the day after you push the final RC artifacts to the Simrel repository).
+
This patch should be contributed to a new Releng bug that will aggregate all the upcoming releng changes for the next release.<br/><br/>
+
 
+
In order to avoid the disruption on the master branch, i.e. shutting down merges until the release, it is recommended to create a new branch based on the release tag and build the release RCP from it. You will have to create a new job on the Integration Instance (you can base it on the Master-RCP job for convenience but do not forget to change the branch). You will then have to modify some references so as to build/integrate against the release and not the nightly:
+
* '''papyrus.repo.main''' should point on the release (do no forget to either change or delete the override in the RCP job itself.
+
* '''papyrus.repo.toolsmiths''' can be updated as well depending on what you are including in the RCP.
+
 
+
The old textual release refenreces should also be updated to the new one as well as the splash screen. To that effect there is an updatable svg in the org.eclipse.papyrus.rcp plugin. From this svg you will be able to generate the required ''splash.bmp'' file; do not forget however that the file should not exceed 400 kBs.
+
 
+
Once all that is done you whould be able to use the Publish-RCP job that will take care of the rest for you. Once the RCPs are on the eclipse servers a final check on the sum and integrity of the archive should be done and you are all set.
+
 
+
 
+
=== Preparing the release ===
+
 
+
To prepare the official release, the final build will have to be copied from <code>milestones/<versionnumber>/<RCx></code> to <code>releases/<versionname>/<releasenumber>/</code> (e.g. ''cp -r ./milestones/2.0/RC4/ ./releases/neon/2.0.2/''). This will allow the indexing of the future release and start the mirroring process.<br/>
+
The copied content should be [https://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#How_is_a_final_build_made_.22invisible.22_until_release.3F '''hidden'''] from the installers to synchronize the release with the train. Usually, as mentionned, moving the '''artifacts''', '''content''', '''category''' and '''p2.index''' files to a dummy ''hidden'' directory should be enough.<br/>
+
You should test what you have done by copy/pasting the ''hidden'' update site in  your installer and verifying that eclipse cannot read any of its content.<br/><br/>
+
You should also start to remove/archive old milestone build as they are not needed anymore and take space (see [https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Release_Process:_How_To#Maintenance Maintenance]). You can keep the RC builds if you have to but that's about it. Do not forget to remove the references contained in the composites (artifact and content).
+
 
+
To do this you will have to log yourself to the '''build.eclipse.org''' repository via an ssh connection (e.g. ''ssh <login>@build.eclipse.org'').
+
 
+
 
+
=== Papyrus Eclipse page ===
+
Do not forget to amend/complete the page dedicated to the release [https://projects.eclipse.org/projects/modeling.mdt.papyrus here]. Verify that all the associated bugs are listed and the new and noteworthy that were integrated are mentioned and references=d.
+
If some bugs were not treated in this release migrate the milestone to the next release.
+
 
+
 
+
=== The day of the release ===
+
 
+
You will now have to:
+
 
# Amend the composites in the release folder to point to the new release
 
# Amend the composites in the release folder to point to the new release
 
# Go to the drops folder and rename the the corresponding stable release ''S2016xxxxx'' to ''R2016xxxxx''
 
# Go to the drops folder and rename the the corresponding stable release ''S2016xxxxx'' to ''R2016xxxxx''
 
# And finally rename the contained zip file from ''Papyrus-Update-xxxRCx'' to ''Papyrus-Update-xxx''
 
# And finally rename the contained zip file from ''Papyrus-Update-xxxRCx'' to ''Papyrus-Update-xxx''
 +
# Merge the prepared patches for the Website and your new development branch
 +
# Update the simrel file
  
 
+
Finally, do not forget to remind the Papyrus Lead, again annoy as needed, to communicate about the release:
=== Papyrus web page ===
+
Prepare a patch with the updated News and Downloads page in order to push them the day of the release. For this you will have to fetch the papyrus-Web repository [http://git.eclipse.org/c/www.eclipse.org/papyrus.git/ here].
+
Update the news, the RCP references and the releases/nightly references provided by the news.xml and download.html for the static page and from there you should be set.
+
 
+
 
+
Finally, do not forget to remind the Papyrus Head to communicate about the release:
+
 
# mail in the mailing list dev
 
# mail in the mailing list dev
 
# post on the forum
 
# post on the forum

Latest revision as of 07:38, 18 September 2019

The Papyrus project is built using Tycho and orchestrated by this releng project.

The release engineer must have:

  • Unrestricted shell access to build.eclipse.org (log a bug to Community/Server to obtain SSH access: see bug 366699). To know if your shell is restricted, try to execute linux commands and see if you get disconnected.
  • The rights to launch jobs on the integration platform : https://hudson.eclipse.org/hudson/ (should come with the Papyrus committer rights, but can be granted by the platform admin)
  • Write access to /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus (should come with the Papyrus committer rights)
  • Subscribed to the cross-project-issues-dev mailing list, on which discussions relevant to the releng activities take place
  • Be aware of the release plan and the step he needs to contribute to, +3 for papyrus, which can be found here


Hudson Jobs

The Papyrus builds are started from Jenkins. The following jobs on the [| Master branch] exist currently. There should always be the following jobs on each release branch:

  • 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 identified as failed, not regressions, kept to keep the main tests clean and without spams
  • papyrus-Master-Toolsmiths : developer tools, such as debug views in eclipse, papyrus diagram code generator, building and customization tools

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


Before starting a build

General Information

Unlike Nightlies, Milestone builds, contributed to the release train, are publicly available to anyone downloading the latest Developer Build of Eclipse. This implies a few differences in terms of quality of the release:

  • All artifacts must be signed, using the Eclipse Certificate
  • The build must be as stable as possible. Especially, any Blocker or Critical bug must be fixed before the release
  • All License files must be available and up-to-date
  • All plug-in metadata must be defined (Especially, bundle name, bundle vendor and feature description)
  • The Papyrus update site must contain everything that is not already contained in the Eclipse Simrel repository (i.e. any plug-in from an Eclipse Project that is not in the release train)


Must Have

As a rule of thumbs, before starting your build journey it is preferable to have a clean install of the Eclipse package you want to test your build against and install the necessary tools and dependencies. You will need to install the following (some may require you to fetch previously build components from other projects that contributes earlier in the train):

Use an Eclipse with Papyrus developer tools installed from the following update site, eg for the XYZ version:

https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ-Toolsmiths/lastSuccessfulBuild/artifact/repository 

This install might need you to posses the following papyrus nightly build address in your available update sites as the developper tools depends on some plugins contained in it:

https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ/lastSuccessfulBuild/artifact/repository/  

Install the tpd updater tool from this Github project from this update site:

https://dl.bintray.com/mbarbero/fr.obeo.releng.targetplatform/latest (4.1.0 and before)
http://download.eclipse.org/cbi/tpd/** (4.2.0 and after)

Papyrus (a clean clone is also useful to have for the builds as it will be much less susceptible to be corrupted by your daily work) up to date:

git://git.eclipse.org/gitroot/papyrus/org.eclipse.papyrus.git 

Simrel on which you will later post your updated aggregator file:

git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git 

Another should have, not mandatory but useful, is the b3 aggregator editor to get a clearer view of the aggregator files in the simrel repository:

https://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Installation


Update Papyrus Dependencies and References

You need to prepare the content for the next release by checking that everything depends on the latest releases of the train and that the versions are all up to date.


Publish The artifacts

When the produced artifacts are successfully produced by the Jenkins job and that you tested their installation and functionalities you will be able to publish them.


Checking the reports

At the end of each milestone you will need to check the installation from the staging update site and check the reports generated by the simrel aggregation job.

The simrel reports are available at :

  • https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/**BuildNumber**/artifact/target/repository/final/buildInfo/reporeports/index.html

And the simrel/staging update site at :

Preparing the GA release

When the final artifacts have been contributed and each milestones have been tagged in the repository, it is time to prepare the for the GA release.


D-day of the GA release

Keep in mind that depending on the date of your release review, you might have an official release day after the GA of the built Eclipse Package.

When your day comes however (means that your release is review and the Eclipse declare the GA official on the cross-project mailing list), you will have to:

  1. Amend the composites in the release folder to point to the new release
  2. Go to the drops folder and rename the the corresponding stable release S2016xxxxx to R2016xxxxx
  3. And finally rename the contained zip file from Papyrus-Update-xxxRCx to Papyrus-Update-xxx
  4. Merge the prepared patches for the Website and your new development branch
  5. Update the simrel file

Finally, do not forget to remind the Papyrus Lead, again annoy as needed, to communicate about the release:

  1. mail in the mailing list dev
  2. post on the forum


This will end the release process. Good job! :)

Maintenance

After a while you will need to move some milestones and releases to the archives, meaning moving them from downloads.eclipse.org to archive.eclipse.org that is not mirrored. It is a good practice as it will save time, space and resources server-wise. The corresponding paths on the server are:

/home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/downloads/drops/
/home/data/httpd/archive.eclipse.org/modeling/mdt/papyrus/downloads/drops/

This can be done manually, until a better solution has been implemented, but be aware of the following guidelines:

  • d.e.o - downloads/drops: keep the last 2 or 3 releases depending on the span you want to cover and that the removed content has been copied in archive of course
  • d.e.o - updates/releases: everything here needs to be kept, do not touch it ;p
  • d.e.o - updates/milestones: this can be handled more loosely, but a good rule of thumb is to keep the last 2 or 3 milestones of what you want to keep in order to

allow eclipse to 'revert to previous installation' if needed.

  • a.e.o - downloads/drops: this needs to contain every releases published. There are no constraint on how recent or old they need to be so if you are not sure you will remember you can copy the release as soon as its out ;). You can also put milestones in here but that is not required.

Back to the top