Skip to main content
Jump to: navigation, search

Papyrus Developer Guide/Release Process: How To/Publish Papyrus Artifacts

< Papyrus Developer Guide‎ | Release Process: How To
Revision as of 09:31, 20 March 2019 by (Talk | contribs) (Created page with "== Publish a build == Successful Nightly builds are automatically published to : * === Before Publishing...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Publish a build

Successful Nightly builds are automatically published to :

Before Publishing

Stable builds are not automatically published. They should be first tested internally before publishing.


To publish a milestone or release from a build, you have to use the following scripts (on the server) under: /opt/public/modeling/mdt/papyrus/

  • 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: ls -la .

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:


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

You should verify that what you have pushed is there :

  • ~/downloads/modeling/mdt/papyrus/downloads/drops/<versionNumber>
  • ~/downloads/modeling/mdt/papyrus/updates/<milestones/releases>/<releaseName>

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 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")

The values to edit

Builds can be hidden from this page before a release by modifying downloads-scripts.php in /downloads/ on git://

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) and push to the simrel's gerrit which path is :

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

<repositories location="" description="Papyrus">
Previous composite address

Updated composite address

Tip: You can check the status of the contribution at simrel's gerrit page

Back to the top