Difference between revisions of "EclipseSCADA/Release/Perform"

Revision as of 10:48, 21 January 2014

This page is work in progress

Preface

Common stuff

All release builds are performed using the "aggregator-release" project -> https://hudson.eclipse.org/scada/job/aggregator-release/

Related pages:

• Common Build Infrastructure/Build Types

This document uses "bash" shell commands and assumes your are running a Linux system with the following tools installed:

• Git
• Java 1.7
• Maven

Naming

Release Branch: 0.1.x-release

Tags (Release): R0.1.0

Tags (Milestone): S0.1.0.M1

Process

For each release cycle there will be a new branch: e.g. 0.1.x-release. On this branch we will force the version qualifiers using our own maven plugin. Qualifiers are generated using the tycho jgit buildtimestamp plugin, but using a custom plugin (org.eclipse.scada.releng:build-helper).

Development goes on in the "master" branch. Changes are merged from the master branch to the release branch. The branch committing the generated qualifiers will be revered (using git revert) and then the master branch will be merged in. This means also that the last commit on the release branch MUST BE the commit of the generated qualifiers.

After the release, so for service releases, the master branch will NOT be merged to the release branch. Changes will me manually merged to the release branch, so the automated merging will not take place.

The generated qualifiers will be committed, tagged and pushed to the release branch after a local build.

The Hudson instance will be used to compile and sign the release branch. It will create a local "staging" directory which will receive the content that will go to download.eclipse.org.

The build is checked and then promoted to the download area.

Check out releng tools

You will need to check out the releng shell scripts:

git clone git://git.eclipse.org/gitroot/eclipsescada/org.eclipse.scada.releng

The shell scripts are under "performRelease". All following commands assume you are in that directory.

You will need to set the environment variable ECLIPSE_COMMITTER to the name of your gerrit account:

export ECLIPSE_COMMITTER=<account>

Change into the project directory:

cd org.eclipse.scada.releng/performRelease/

Prepare new release branch

This step is only done once per minor release
This means branches: 0.1, 0.2, … Milesone releases and service releases will go to the same branch

Create a new branch for each release cycle: e.g. 0.1.x-release

Edit the file "profile" and update the branch name.

Execute:

./createBranch

Check the output in the "workspace" directory.

Push the branch to gerrit:

./pushBranch

Changes on the master must be merged to the release branch during the release cycle. New features that should not be included in the release must go to separate feature branches. After the final release is performed they may be merged on the master.

If it turns out that merging on the release branch is to cumbersome we will make branches for every release tag in order to prevent merge issues.

Checkout release branch

The release branch is automatically checked out by the "createTag" script.

Create new release tag

Create a new tag for a new release during the release cyclce.

Edit the file "profile" and update the qualifier name.

Execute:

./createTag -m

Or, if this is the first tag of a new release branch:

./createTag

Check the output in the "workspace" directory.

Build locally:

./buildLocally

Wait and check the output in /tmp/my-download-test

Output from the local build is not signed

If everything looks good push the commit and tag.

Push release commit and tag

Push the forces qualifiers and the tag:

./pushTag

Check https://git.eclipse.org/c if the changes made it to gerrit.

Perform build

Perform the build on the Eclipse SCADA Hudson instance

• Job: https://hudson.eclipse.org/scada/job/org.eclipse.scada.releng.superParent/
• Wait for the job to complete!
• Job: https://hudson.eclipse.org/scada/job/aggregator-release/

The result is in the directory "staging" under the workspace of the project "aggregator-release".

Test

The usual…

Promote

For this job to work the output of the previous build step must still be present in the workspace of the job.

• Run the CI job -> https://hudson.eclipse.org/scada/job/promote-release/

This job will copy (using local rsync) the output of the build to the download area.

A the moment this job complains about some directory that cannot be copied, since it already exists, and therefore fails the build
This is not a problem.