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

OCL/Dev/Releng/Cheatsheet

How to Releng MDT OCL

This is a very brief cheat sheet on how to publish builds for MDT OCL.

First, there are several types of builds:

N-builds: Nightly builds are internal-purpose builds which reflect the current state of the development stream. They do NOT use CVS tags in ocl.map and check out the current HEAD state. These builts are NOT signed and CANNOT be published.

I-builds: Integration builds usually reflect the intermediate state of the product. These are done between the milestones and rely on the CVS tags, i.e. their content may differ from the current CVS HEAD state.

S-builds: Stable (milestone and release) builds are actually I-builds which have a different naming than I-builds.

The releng process consists of two main phases - assembling (running) the build and publishing it on the downloads page and the update site (promotion).

How to Run an N-build

N-builds are run automatically triggered by CVS commits. However, they can be launched manually.

1. Navigate to https://build.eclipse.org/hudson/job/cbi-mdt-ocl-3.0/

2. Log in using your CVS credentials

3. Click "Build Now".

4. On the next page, do not change the default build parameters and press "Build".

How to make an I-build

Launching an I-build is as simple as running an N-build. However, since I-builds use CVS tags in ocl.map rather than CVS HEAD state there is usually a preparation step. The goal of this step is to tag the new CVS changes which occurred after the last I-build and to update the tags in ocl.map.

Tagging the sources and updating the ocl.map

There are several ways to perform this part, e.g. manually using Eclipse Team integration. However, I prefer the automated approach based on the Releng Tools project. Both approaches are described in this section.

Tagging by hand

1. In the Navigator, select the plugin project(s) which were changed since the last I-build. 2. In the popup menu select Team->Tag as Version 3. In the Tag Resources dialog enter the new tag. Usually, the vYYYYMMDDHHmm form is used, e.g. v201004240200. Use Details->Refresh Tags buttons to explore the tags which have been already used. 4. Click OK

After you tag all the changed plugin projects you need to update your ocl.map file located in org.eclipse.mdt/org.eclipse.ocl/releng/maps/. In the ocl.map file update the lines corresponding to the plugins you have just tagged to the new tag value.

The map file is a Java properties file where the entries have the following format (for CVS): element@element_id=tag,:connection_type:user@host:repository

The SVN entry format is described here http://wiki.eclipse.org/Subversive_PDE_Fetch .

Tagging with Releng Tools

Although you can manually tag the sources as described above, for most cases it is much easier to use Releng Tools.

Prerequisites: 
1. Releng Tools plugin from http://download.eclipse.org/eclipse/updates/3.6milestones.
2. OCL plugin projects from CVS HEAD must be imported to the active working set.
3. The OCL releng project (org.eclipse.mdt/org.eclipse.ocl/releng) or the parent org.eclipse.ocl project from CVS HEAD
   must be imported to the active working set.

To tag with Releng Tools you will need to:

1. Update the projects from CVS

2. Invoke popup menu in the Navigator and select Team->Release...

3. Select the project containing the ocl.map file (org.eclipse.mdt/org.eclipse.ocl/releng or org.eclipse.mdt/org.eclipse.ocl).

4. Select ocl.map in the dialog page and check that the project list contains actual OCL projects (There can be other projects in your workspace - if so, uncheck them).

5. Check "Release only projects that have changed since the last release".

6. Click "Next". The routine will scan through the selected projects from the ocl.map and filter those which have changed since the last I-build.

7. The next page will show the recent changes - here you can check that everything goes well.

8. On the next page, enter the new tag. Usually, the vYYYYMMDDHHmm form is used, e.g. v201004240200.

9. Observe the changes in the ocl.map which will be committed.

10. Commit the ocl.map file with a thoughtful comment.

Launching the I-build

You can launch an I build in the same manner as an N-build.

1. Navigate to https://build.eclipse.org/hudson/job/cbi-mdt-ocl-3.0-integration/.

2. Log in using your CVS credentials

3. Click "Build Now".

4. On the next page, do not change the default build parameters and press "Build".

Publishing the I-build

Before publishing the I-build make sure that your I-build has been successful. Check its status and console log if necessary.

The promotion step (publishing) is not very convenient at the moment. To do so, you must ssh to build.eclipse.org and start the promotion script from the console.

Prerequisites: An ssh client tool. My favourite is PUTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html).

1. Ssh to build.eclipse.org at port 22.

2. Log in using your CVS credentials.

3. If you do it first time, go to my scripts folder: /home/data/users/aigdalov/scripts and copy the following files to your home folder

- promote_ocl_3_0_0_I.sh // a tiny script which promotes an I-build
- promote_ocl_3_0_0_S.sh // a tiny script which promotes an S-build
- promote.xml
- promote-I.properties
- promote-S.properties

4. Run promote_ocl_3_0_0_I.sh

5. After the script is finished check that the new build has appeared on the downloads page (http://www.eclipse.org/modeling/mdt/downloads/index.php?project=ocl)

NB: Mirror servers are synchronized automatically with build.eclipse.org. No manual action is required.

How to make an S-build

Making an S-build is similar to making an I-build.

Tagging for the S-build

See the corresponding I-builds section.

Launching the S-build

Back to the top