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

EMF Compare/Build

Build job locations

The latest version can always be built with the master-nightly job.

p2 repositories (a.k.a. update sites) locations

EMF Compare builds are stored in p2 repositories that are produced as part of the build process. This section provides an overview of the different repositories maintained by the EMF Compare project, and their corresponding location and retention policy.

EMF Compare update sites are located on the server build.eclipse.org within the folder /home/data/httpd/download.eclipse.org/modeling/emf/compare/updates.

Launching a Build

Members of the EMF Compare team are the only persons that can launch builds. You will need to be connected to hudson and on the page of the job you want to run (see above).

The build takes a single parameter, the reference target platform, which determines the target eclipse version.

Promotion Instructions

  • Launch build on the required hudson job. Let's assume here that you build the latest version through job master-nightly.
  • Once the build has passed
    • Look at the log and search for the string "org.eclipse.emf.compare-feature/target"
    • Just a few lines under that is "The project's OSGi version is x.x.x.yyyyMMddhhmm"
    • Copy that version
  • Go to the manual publishing job at https://hudson.eclipse.org/emfcompare/job/publish-milestone-manual

This build takes two parameters, none of which can be empty: QUALIFIER is the version you've copied just above. Paste it in there. ALIAS is the human readable name for this milestone. By convention, this is "x.x.x<optional milestone name>", for example 3.3.1M7 or 3.3.1RC2.

Changing the aggregator (simultaneous release)

  • Clone the simrel repository
    • git clone ssh://<user>@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git/
  • Install the b3 editor in the eclipse where you'll change the aggregation (for an Eclipse 4.2, it can be installed from http://download.eclipse.org/modeling/emft/b3/updates-4.2)
  • Checkout the simrel project in your eclipse, on the accurate branch (e.g. Juno_maintenance for Juno, master for the current release train)
  • Open the main simrel file (simrel.b3aggr) with the b3 editor
  • Locate the EMF Compare entry, and change the update site it references so that it points toward the latest milestone (it should be available at "http://download.eclipse.org/modeling/emf/compare/updates/milestones/x.x/SyyyyMMddhhmm", "x.x" and "yyyyMMddhhmm" being the parts of the qualifier you used above to start the publishing job).
  • Make sure that the file validates (right-click within the b3 editor, then select "Validate Aggregation")
  • Commit and push the modification for review
    • There should only be changes in the emf-compare.b3aggrcon file.
  • If the review is succesfully verified by hudson, +2 and push it to the repository.


PENDING DELETION - need to create a hudson job to copy the latest RC as a R build.

For the release

The R build will be a copy of the latest RC that was promoted. Promoting the release will be made in two steps : creating the release build, then making it available ; the latter of which should only be done the day of the official release train's release.

Creating the release build

Let's assume "2.1.0" is the released version here, assume the qualifier of the latest RC, "2.1.0RC4", is 201306110000. All of the following is done on build.eclipse.org.

zips

  • Go to the "drops" folder corresponding to your release
    • cd /home/data/httpd/download.eclipse.org/modeling/emf/compare/downloads/drops/2.1.0
  • copy the folder of the latest RC into a folder with the same qualifier, but with the "R" prefix instead of "S"
    • cp -r S201306110000 R201306110000
  • Go into this new folder
    • cd R201306110000
  • Rename all zips and md5 to remove their "RC" alias
    • mv emf-compare-update-2.1.0RC4.zip emf-compare-update-2.1.0.zip
    • mv emf-compare-update-2.1.0RC4.zip.md5 emf-compare-update-2.1.0.zip.md5
  • Change the md5 to remove the alias from the file names
    • vi emf-compare-update-2.1.0.zip.md5
  • Check all md5, it must be OK
    • md5sum -c *.md5
  • Hide the zip from the download page (this should be done on your own machine, not on build.eclipse.org)
  • Make sure that the zip does not appear on http://www.eclipse.org/emf/compare/downloads/

update site

  • Go to the "releases" folder of the project and create the version's folder if it does not exist yet :
    • cd /home/data/httpd/download.eclipse.org/modeling/emf/compare/updates/releases/
    • mkdir 2.1
    • cd 2.1
  • Create a folder for the release, with the same qualifier as above
    • mkdir R201306110000
    • cd R201306110000
  • Use the mirroring script to replicate the latest RC in this folder
    • ant -f /shared/modeling/tools/promotion/mirror-repository.xml -Drepository=/home/data/httpd/download.eclipse.org/modeling/emf/compare/updates/milestones/2.1/S201306110000/
you might get "unable to satisfy dependency" warnings while mirroring, this isn't an issue at this point.

Making the build available

This must not be done before the day of the official release.

  • Unhide the zip from the download page (this should be done on your own machine, not on build.eclipse.org)
    • cd org.eclipse.emf.compare.website/downloads
    • vi index.php
      • locate the "$hiddenBuilds" variable, and remove the zip you wish to make available from that array : "2.1.0" => array("R201306110000")
  • Add the release update site to the composite update site of the released version
    • ssh build.eclipse.org
    • cd /home/data/httpd/download.eclipse.org/modeling/emf/compare/updates/releases/2.1
    • ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=R201306110000 -Dcomposite.name="EMF Compare 2.1 Releases"


Checklist

Standard build

Milestone build

First follow all steps of the standard builds. Then :

  • Create a tag for the build, named after the alias and containing the qualifier in the message. For example our 2.1.0M7 was tagged with :
    • git tag -a '2.1.0M7' -m 'EMF Compare 2.1.0M7 - Luna M7 - 201305060839'
    (git tag -a '<alias>' -m '<message>' <optional SHA-1 of commit to tag>)
  • Check that the commit is properly tagged
    • git show 2.1.0M7
  • Share the tag
    • git push origin 2.1.0M7
  • Retrieve the simultaneous release's repository
  • Make sure that the aggregation references the aggregate milestones update site
  • And validate the model (right click > Validate aggregation)
  • Check the aggregation (example for Kepler)
    (The lines of interest mostly start with "mirroring artifact osgi.bundle".)
    • If an older qualifier appears
      • Re-open the simrel.b3aggr file, and change it so that it references the "latest milestone only" update site. This will prevent the aggregation from "finding" older builds.
      • Re-launch the aggregation (you can cancel it manually if the one running was one you launched).
      It will most likely fail, but this time the logs will show "who" requires an older version of EMF Compare.
      • Send a mail to the incriminated project's team or on the cross-projects list to see if they can update their EMF Compare dependency.
    • If the aggregation job fails
      • The most likely reason is a validation failure of the simrel.b3aggr file.
      • If you cannot debug the issue, re-open the simrel.b3aggr file and disable the EMF Compare contribution until the problem can be fixed. Mail the cross-project list for help.

Release

First follow all steps of the standard builds. Then :

  • Create a tag for the build, named after the version and containing the qualifier in the message. For example to tag the EMF Compare 2.1.0 release :
    • git tag -a '2.1.0' -m 'EMF Compare 2.1.0 - 201311060000'
    (git tag -a '<alias>' -m '<message>' <optional SHA-1 of commit to tag>)
  • Check that the commit is properly tagged
    • git show 2.1.0
  • Share the tag
    • git push origin 2.1.0



  • Make sure that the aggregation references the update site containing only the latest release
  • Check the aggregation (example for Kepler)
    (The lines of interest mostly start with "mirroring artifact osgi.bundle".)
    • If an older qualifier appears
      • Re-open the simrel.b3aggr file, and change it so that it references the "latest release only" update site. This will prevent the aggregation from "finding" older builds.
      • Re-launch the aggregation (you can cancel it manually if the one running was one you launched).
      It will most likely fail, but this time the logs will show "who" requires an older version of EMF Compare.
      • Send a mail to the incriminated project's team or on the cross-projects list to see if they can update their EMF Compare dependency.
    • If the aggregation job fails
      • The most likely reason is a validation failure of the simrel.b3aggr file.
      • If you cannot debug the issue, re-open the simrel.b3aggr file and disable the EMF Compare contribution until the problem can be fixed. Mail the cross-project list for help.


Retrieved from "https://wiki.eclipse.org/index.php?title=EMF_Compare/Build&oldid=416456"

Back to the top