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.
Difference between revisions of "OCL/Dev/Releng/Cheatsheet"
(→Tagging by hand) |
|||
| Line 5: | Line 5: | ||
First, there are several types of builds: | 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. | + | '''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. | '''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. | ||
| Line 21: | Line 21: | ||
2. Log in using your CVS credentials | 2. Log in using your CVS credentials | ||
| − | 3. Click "Build Now". | + | 3. Click "''Build Now''". |
| − | 4. On the next page, do not change the default build parameters and press "Build". | + | 4. On the next page, do not change the default build parameters and press "''Build''". |
== How to make an I-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. | + | 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 === | === Tagging the sources and updating the ocl.map === | ||
| Line 43: | Line 43: | ||
4. Click ''OK'' | 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. | + | 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): | The map file is a Java properties file where the entries have the following format (for CVS): | ||
| Line 58: | Line 58: | ||
1. Releng Tools plugin from http://download.eclipse.org/eclipse/updates/3.6milestones. | 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. | 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 | + | 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. | must be imported to the active working set. | ||
| Line 65: | Line 65: | ||
1. Update the projects from CVS | 1. Update the projects from CVS | ||
| − | 2. Invoke popup menu in the Navigator and select Team->Release... | + | 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). | + | 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). | + | 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". | + | 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. | + | 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. | 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. | + | 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. | + | 9. Observe the changes in the ''ocl.map'' which will be committed. |
| − | 10. Commit the ocl.map file with a thoughtful comment. | + | 10. Commit the ''ocl.map'' file with a thoughtful comment. |
=== Launching the I-build === | === Launching the I-build === | ||
| Line 91: | Line 91: | ||
2. Log in using your CVS credentials | 2. Log in using your CVS credentials | ||
| − | 3. Click "Build Now". | + | 3. Click "''Build Now''". |
| − | 4. On the next page, do not change the default build parameters and press "Build". | + | 4. On the next page, do not change the default build parameters and press "''Build''". |
=== Publishing the I-build === | === Publishing the I-build === | ||
| Line 99: | Line 99: | ||
Before publishing the I-build make sure that your I-build has been successful. Check its status and console log if necessary. | 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. | + | 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). | 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. | + | 1. Ssh to ''build.eclipse.org'' at port ''22''. |
2. Log in using your CVS credentials. | 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 | + | 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 |
- [[MDT/OCL/Dev/Releng/Cheatsheet/promote_ocl_3_0_0_I.sh|promote_ocl_3_0_0_I.sh]] // a tiny script which promotes an I-build | - [[MDT/OCL/Dev/Releng/Cheatsheet/promote_ocl_3_0_0_I.sh|promote_ocl_3_0_0_I.sh]] // a tiny script which promotes an I-build | ||
| Line 115: | Line 115: | ||
- [[MDT/OCL/Dev/Releng/Cheatsheet/promote-S.properties|promote-S.properties]] | - [[MDT/OCL/Dev/Releng/Cheatsheet/promote-S.properties|promote-S.properties]] | ||
| − | 4. Run promote_ocl_3_0_0_I.sh | + | 4. Run ''promote_ocl_3_0_0_I.sh'' |
| − | 5. After the script is finished check that the new build has appeared on the | + | 5. After the script is finished check that the new build has appeared on the [http://www.eclipse.org/modeling/mdt/downloads/index.php?project=ocl downloads page] |
| − | NB: Mirror servers are synchronized automatically with build.eclipse.org. No manual action is required. | + | NB: Mirror servers are synchronized automatically with ''build.eclipse.org''. No manual action is required. |
== How to make an S-build == | == How to make an S-build == | ||
| Line 138: | Line 138: | ||
- EXTRAFLAGS: -buildAlias 3.0.0M7 // if you are building RC2 for 3.0.0 it will be 3.0.0RC2 | - EXTRAFLAGS: -buildAlias 3.0.0M7 // if you are building RC2 for 3.0.0 it will be 3.0.0RC2 | ||
| − | and press "Build". | + | and press "''Build''". |
=== Publishing the S-build === | === Publishing the S-build === | ||
| Line 144: | Line 144: | ||
The same as for I-builds except | The same as for I-builds except | ||
| − | 4. Run promote_ocl_3_0_0_S.sh | + | 4. Run ''promote_ocl_3_0_0_S.sh'' |
| − | == Including OCL into Helios == | + | == Including MDT OCL into Helios == |
| − | After the publishing process is successfully finished the S-build (sometimes the I-build) has to be included into the Eclipse train. | + | After the publishing process is successfully finished the S-build (and sometimes the I-build) has to be included into the Eclipse train. |
| − | To do so, one needs to update the /org.eclipse.helios.build/mdt-ocl.build at /cvsroot/callisto at dev.eclipse.org. | + | To do so, one needs to update the ''/org.eclipse.helios.build/mdt-ocl.build'' at ''/cvsroot/callisto'' at ''dev.eclipse.org''. |
| − | 1. Modify the ''version'' attribute of the org.eclipse.ocl.all.sdk feature. Go to http://download.eclipse.org/modeling/mdt/ocl/3_0/updates/milestones/site.xml to copy the feature ID. | + | 1. Modify the ''version'' attribute of the ''org.eclipse.ocl.all.sdk'' feature. Go to http://download.eclipse.org/modeling/mdt/ocl/3_0/updates/milestones/site.xml to copy the feature ID. |
2. Run the Helios build at https://build.eclipse.org/hudson/job/helios.runBuckyBuild/. | 2. Run the Helios build at https://build.eclipse.org/hudson/job/helios.runBuckyBuild/. | ||
3. Make sure that it has completed successfully. | 3. Make sure that it has completed successfully. | ||
Revision as of 12:56, 26 April 2010
Contents
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 builds are milestone and release builds published on schedule in the project plan.
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
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
The same as for I-builds.
Launching the S-build
The same as for I-builds except
4. On the next page, set the following build parameters
- BUILDTYPE: S - EXTRAFLAGS: -buildAlias 3.0.0M7 // if you are building RC2 for 3.0.0 it will be 3.0.0RC2
and press "Build".
Publishing the S-build
The same as for I-builds except
4. Run promote_ocl_3_0_0_S.sh
Including MDT OCL into Helios
After the publishing process is successfully finished the S-build (and sometimes the I-build) has to be included into the Eclipse train.
To do so, one needs to update the /org.eclipse.helios.build/mdt-ocl.build at /cvsroot/callisto at dev.eclipse.org.
1. Modify the version attribute of the org.eclipse.ocl.all.sdk feature. Go to http://download.eclipse.org/modeling/mdt/ocl/3_0/updates/milestones/site.xml to copy the feature ID.
2. Run the Helios build at https://build.eclipse.org/hudson/job/helios.runBuckyBuild/.
3. Make sure that it has completed successfully.