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

Difference between revisions of "OCL/Dev/Releng/Tycho"

< OCL
(Created page with "== MDT OCL Releng Introduction == This is a very brief cheat sheet on how to make and publish builds for Eclipse OCL project. First, there are several types of builds: ''...")
 
(Updating Eclipse OCL in the Eclipse SimRel Release Train)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== MDT OCL Releng Introduction ==
 
== MDT OCL Releng Introduction ==
  
This is a very brief cheat sheet on how to make and publish builds for Eclipse OCL project.
+
This is a very brief cheat sheet on how to make and publish builds for the Eclipse OCL project.
  
 
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, that is, using the current GIT master HEAD.
 
  '''N'''-builds: Nightly builds are internal-purpose builds which reflect the current state of the development stream, that is, using the current GIT master HEAD.
 
 
  '''I/M'''-builds: Integration/Interim builds.
 
  '''I/M'''-builds: Integration/Interim builds.
 
 
  '''S'''-builds: Stable/Milstone/Release-Candidate builds.
 
  '''S'''-builds: Stable/Milstone/Release-Candidate builds.
 
 
  '''R'''-builds: Release builds.
 
  '''R'''-builds: Release builds.
  
The regular releng process consists of two cascaded builds.
+
The regular releng process consists of two cascaded builds. They are triiggered Monday to Saturday by GIT changes or manual requests. They are forcibly triggered on Sun days to get early detection of dependency breakages.
 
+
https://ci.eclipse.org/ocl/job/ocl-master assembles and tests the build and if successful
+
  
 +
https://ci.eclipse.org/ocl/job/ocl-master assembles and tests a build of the master branch and if successful
 
  https://ci.eclipse.org/ocl/job/promoter publishing it on the downloads page and the P2 repository (promotion).
 
  https://ci.eclipse.org/ocl/job/promoter publishing it on the downloads page and the P2 repository (promotion).
 +
 +
Additional manual jobs
 +
 +
https://ci.eclipse.org/ocl/job/ocl-branch-tests assembles and tests a build of a specified branch
 +
https://ci.eclipse.org/ocl/job/shell executes a command line on the build server
 +
 +
Additional automatic jobs run every Sunday after the master build
 +
 +
https://ci.eclipse.org/ocl/job/ocl-ecore-standalone runs the Classic Ecore tests on the latest build using Java 5
 +
https://ci.eclipse.org/ocl/job/ocl-uml-standalone runs the Classic UML tests on the latest build using Java 5
 +
https://ci.eclipse.org/ocl/job/ocl-codegen-tests runs the additional slow Pivot Code Generator test on the latest build
 +
e.g https://ci.eclipse.org/ocl/job/ocl-compatibility-2019-03 runs the tests on an Eclipse 2019-03 platform using the latest build
  
 
== How to Run a Build ==  
 
== How to Run a Build ==  
'''N'''-builds are run automatically when a CVS change is detected (CVS is monitored every 6 hours). '''I''', '''S''', '''R''', and '''M'''-builds must be manually launched.
+
'''N'''-builds are run automatically on Sundays or when a GIT change is detected (GIT is monitored every 6 hours). '''I''', '''S''', '''R''', and '''M'''-builds must be manually launched.
  
# Navigate to https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/
+
# Navigate to ''https://ci.eclipse.org/ocl/job/ocl-master''
# Log in using your CVS credentials
+
# Log in using your Eclipse credentials
# Click "''Build Now''".
+
# Click "''Build with Parameters''".
# On the next page, select the correspondent build type. In case you need to publish a milestone/release/maintenance build, you may want to use a proper build alias for the build. For instance, to create an ''M2'' milestone for MDT/OCL Indigo, you have to select the '''S'''-build type and establish "'''3.1.0M2'''" as the build alias.
+
# Select the build type and if publishing a milestone/release/maintenance build, specify alias for the build. For instance, to create an ''M2'' milestone for MDT/OCL Indigo, you have to select the '''S'''-build type and establish "'''3.1.0M2'''" as the build alias.
 
# Finally, you must press "''Build''" to start the build.
 
# Finally, you must press "''Build''" to start the build.
  
 
== How to Publish a Build ==
 
== How to Publish a Build ==
  
'''N'''-builds are usuallaly published in an automated way. A cron entry defined by the release engineer is responsible to execute the publishing script every night:
+
Builds are published automatically by the promter job provided the preceding build job was successful.
  
30 3 * * * ant -f /shared/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/archive/publishroot/publisher.ant
+
NB: Mirror servers are synchronized automatically with ''build.eclipse.org''. No manual action is required.
-Dbuild.root=/opt/public/jobs/buckminster-mdt-ocl-core-3.1-nightly/lastSuccessful/
+
&> logs/mdt-ocl-publishing.log
+
  
Specifically, this ant task publishes the last successful build so that if you wanted to publish a manually executed (and succesfully completed) build you would only require to execute that command in a shell on ''build.eclipse.org'' server. To access this server, you have to use a ssh client tool (i.e ''PUTTY'') and do the following:
+
== Updating Eclipse OCL in the Eclipse SimRel Release Train ==
  
# Ssh to ''build.eclipse.org'' at port ''22''.
+
After the publishing process is successfully finished the '''S/R/M'''-build has to be included into the Eclipse release train.
# Log in using your CVS credentials.
+
# Execute the ant task above.
+
  
NB: If it's the first time you access Eclipse's servers, you need to be granted with shell access to log in.
+
To do so, one needs to update the Eclipse OCL contribution to the SimRel project.
In order to obtain said shell access, tell your project leader to do the request.
+
Example: https://bugs.eclipse.org/bugs/show_bug.cgi?id=310790.
+
  
NB: Mirror servers are synchronized automatically with ''build.eclipse.org''. No manual action is required.
+
In a web browser, if not already set up and assuming ''xyzzy'' is your Eclipse committer id
 +
# create the ''https://github.com/xyzzy/simrel.build'' fork of ''eclipse-simrel/simrel.build:main''.
  
== Including MDT OCL into the Eclipse Release Train ==
+
In Eclipse, if not already set up:
 +
# Clone ''https://github.com/eclipse-simrel/simrel.build.git''
  
After the publishing process is successfully finished the '''S/R/M'''-build has to be included into the Eclipse release train.
+
In Eclipse:
 +
# Check out the ''main'' branch
 +
# Pull from ''origin''
 +
# Create and checkout a Pull Request branch such as ''pr-ocl''
 +
# Edit the ''/org.eclipse.simrel.build/ocl.aggrcon'' file (GIT history has numerous examples)
 +
# Commit the edit
 +
# Push the PR branch to ''xyzzy'' specifying ''pr-ocl''
  
To do so, one needs to update the MDT/OCL contribution to the correspondent release project (i.e ''org.eclipse.indigo.build'') at ''/cvsroot/callisto'' at ''dev.eclipse.org'':
+
(NB OCL and QVTd are tightly coupled so often committed together).
  
# Open the ''mdt-ocl.b3aggrcon'' file.
+
Back in a web browser and provided you have simrel committer rights
# Ensure that you are using the proper repository location (i.e To contribute a milestone for Indigo release train: http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0).
+
# Navigate to ''https://github.com/xyzzy/simrel.build''
# Ensure that you are using the proper verion attribute of the ''org.eclipse.ocl.all.sdk'' and ''org.eclipse.ocl.examples'' features. (i.e you could check the version of the feature, checking the correspondent repository: http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0/features/).
+
# Accept the offered ''pr-ocl'' PR - click Compare and pull request
# Run the Helios release train build (i.e Indigo's Hudson job:  https://hudson.eclipse.org/hudson/job/indigo.runAggregator/).
+
# click Create pull request
# Make sure that the build has been successfully completed.
+
# wait while auto-build proceeds
 +
# Click rebase and merge (not squash and merge which changes Committer to GitHub)
 +
# Click Confirm rebase and merge
 +
# Click Delete branch

Latest revision as of 14:59, 26 February 2024

MDT OCL Releng Introduction

This is a very brief cheat sheet on how to make and publish builds for the Eclipse OCL project.

First, there are several types of builds:

N-builds: Nightly builds are internal-purpose builds which reflect the current state of the development stream, that is, using the current GIT master HEAD.
I/M-builds: Integration/Interim builds.
S-builds: Stable/Milstone/Release-Candidate builds.
R-builds: Release builds.

The regular releng process consists of two cascaded builds. They are triiggered Monday to Saturday by GIT changes or manual requests. They are forcibly triggered on Sun days to get early detection of dependency breakages.

https://ci.eclipse.org/ocl/job/ocl-master assembles and tests a build of the master branch and if successful
https://ci.eclipse.org/ocl/job/promoter publishing it on the downloads page and the P2 repository (promotion).

Additional manual jobs

https://ci.eclipse.org/ocl/job/ocl-branch-tests assembles and tests a build of a specified branch
https://ci.eclipse.org/ocl/job/shell executes a command line on the build server

Additional automatic jobs run every Sunday after the master build

https://ci.eclipse.org/ocl/job/ocl-ecore-standalone runs the Classic Ecore tests on the latest build using Java 5
https://ci.eclipse.org/ocl/job/ocl-uml-standalone runs the Classic UML tests on the latest build using Java 5
https://ci.eclipse.org/ocl/job/ocl-codegen-tests runs the additional slow Pivot Code Generator test on the latest build
e.g https://ci.eclipse.org/ocl/job/ocl-compatibility-2019-03 runs the tests on an Eclipse 2019-03 platform using the latest build

How to Run a Build

N-builds are run automatically on Sundays or when a GIT change is detected (GIT is monitored every 6 hours). I, S, R, and M-builds must be manually launched.

  1. Navigate to https://ci.eclipse.org/ocl/job/ocl-master
  2. Log in using your Eclipse credentials
  3. Click "Build with Parameters".
  4. Select the build type and if publishing a milestone/release/maintenance build, specify alias for the build. For instance, to create an M2 milestone for MDT/OCL Indigo, you have to select the S-build type and establish "3.1.0M2" as the build alias.
  5. Finally, you must press "Build" to start the build.

How to Publish a Build

Builds are published automatically by the promter job provided the preceding build job was successful.

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

Updating Eclipse OCL in the Eclipse SimRel Release Train

After the publishing process is successfully finished the S/R/M-build has to be included into the Eclipse release train.

To do so, one needs to update the Eclipse OCL contribution to the SimRel project.

In a web browser, if not already set up and assuming xyzzy is your Eclipse committer id

  1. create the https://github.com/xyzzy/simrel.build fork of eclipse-simrel/simrel.build:main.

In Eclipse, if not already set up:

  1. Clone https://github.com/eclipse-simrel/simrel.build.git

In Eclipse:

  1. Check out the main branch
  2. Pull from origin
  3. Create and checkout a Pull Request branch such as pr-ocl
  4. Edit the /org.eclipse.simrel.build/ocl.aggrcon file (GIT history has numerous examples)
  5. Commit the edit
  6. Push the PR branch to xyzzy specifying pr-ocl

(NB OCL and QVTd are tightly coupled so often committed together).

Back in a web browser and provided you have simrel committer rights

  1. Navigate to https://github.com/xyzzy/simrel.build
  2. Accept the offered pr-ocl PR - click Compare and pull request
  3. click Create pull request
  4. wait while auto-build proceeds
  5. Click rebase and merge (not squash and merge which changes Committer to GitHub)
  6. Click Confirm rebase and merge
  7. Click Delete branch

Back to the top