Promoting a Release Build

gholms edited this page Mar 29, 2013 · 2 revisions


This page is intended to be used by the Eucalyptus Release Engineering team. It provides documentation for the internal process of promoting a build for release to the public.

Selecting a build to promote

In order to promote a release of Eucalyptus, one must first SSH to the internal staging server. This server mirrors the contents of the public-facing Downloads Server. Once logged into the server, change to the directory where promotion scripts are located:

$ cd /opt/nightly/build

In this directory there are a number of different shell scripts that are used to do promotions of nightly, milestone, and release builds. In order to do the promotion of a release build you will need to run the script. You'll need to supply two arguments: the commit hash and the version number.

Please note that the commit hash is actually any reference that the package API understands. It can be a hash, tag or branch.

For example, if your commit hash was 1234567890 and the version you are releasing is 3.3, you would run the following command:

$ sudo ./ 1234567890 3.3

This command will query the package API to determine if the commit hash is valid for the internal Eucalyptus repository. If it is, it will create a new repository for the proprietary packages if one does not exist, or merge the packages into the existing repository. Then the script will check which version of the eucalyptus(abi) the proprietary packages require. This is the version of the Eucalyptus open source packages that will be promoted. Again, a new repository will be created or the packages will be merged into the existing repository.

Please note that doing a release promotion will not promote the packages to the public server. It will only select the packages to promote and merge them into repositories on the internal staging server. This is because typically SA and GA do not occur on the same day. At a later time an rsync will need to be run to promote these packages to the public server.

Promotion best practices

Always do a backup

Before running the promotion scripts, it's best to make a backup of the repositories that will be updated. For instance, if are promoting a release of version 3.2, then first backup the 3.2 directory. If for any reason the promotion does not turn out like you expect you can reverse your changes.

Checking for packages prior to promotion

You can also check to see if a particular build exists before running the promotion script by using the Arado tools directly. Since the tools need to use a virtualenv you'll first need to put the correct Python into your path, as well as the path to the tools.

$ export PATH=/opt/nightly/aradopy/bin:/opt/nightly/arado:$PATH

Now you can run any of the Arado tools that you would like. If you want to check if a build exists and what the package contents of that build are, you can run a command like this:

mspaulding@release-repo:/opt/nightly/arado$ arado-describe-build -p eucalyptus -c 3.3-m4

In order to use the arado-describe-build tool, you will need to specify a project and commit as was done for the example above. A commit can be any type of commit reference that Git understands, like a commit hash, tag or branch. After the running the command and verifying that the packages you want to promote are available and the correct ones, you can run the promotion process.


Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.