CASA Continuous Build/Test Server User Guidelines

This page provides guidelines for using the CASA Continuous Build/Test (CBT) Servers (casa-jenkins and casa-cbts) to maximize the benefits of these servers for all CASA developers.

These guidelines are consistent with the practice of Continuous integration, but are still useful if you do not practice Continuous Integration.


Note: The table of contents provides an outline of the procedure to follow.

Before You Commit

Allow Time for Your Change to be Built and Tested

Do not commit changes to change control just before stopping work for the day (or for lunch). A failed build, not corrected quickly, can slow down other CASA developers.

Allow enough time for your change to build on the CBT server, for tests to run, and for you to check the results. Do not commit a change if you have less than the following time left in your work day.

build component allow at least
casacore 90 minutes
code 60 minutes
gcwrap 30 minutes
asap 15 minutes

These are minimums. They will be adjusted based on observed build and test times.

Check If the Build is Healthy

See the most recent build on the CASA Production CBT server for the branch you are working on.

Below is a subset of the Jenkins build history for the CASA Trunk.


Healthy builds are indicated by a blue ball in the first column of the build history. Broken builds indicated by a red ball.

Healthy Build

If the latest build is healthy, proceed with your commit.

Broken Build

If the latest build is broken, allow the developer responsible for the change that broke the build time to fix it. Check back in a few minutes and try again.

The following practice is discouraged, unless you are fixing a build for someone else, as it can hinder the developer trying to fix a broken build. But, if you just can't wait for the broken build to be fixed,

  1. check the build logs for the broken build to see if your change will be built before the broken portion of the build. If so, then
  2. commit your change, and check the build logs to verify your change builds correctly.

With this approach, you will lose the benefit of post build testing. If you do this, you are responsible for checking build results for your change and verifying your change did not introduce another build problem.

After You Commit

If Your Commit Failed

Send mail to casa-staff reporting you are working on fixing the CBT server build. Then, either fix the CBT server build immediately, or , if you can't fix the build immediately, revert your commit immediately (instructions below). Once the CBT server build is healthy, report to to casa-staff that you have fixed the CBT server build.

To revert a commit to Subversion, use the commands

svn merge -c -[revision number] .
svn commit -m 'Reverting r[revision number], because it broke the build.  Will try again later.'

where [revision number] is the Subversion revision of your commit. Do not include "r" in the command. For example:

svn merge -c -23677 .
svn commit -m 'Reverting r23677, because it broke the build.  Will try again later.'

Your change will remain in the change control history, so you can try again some other time when you have more time to resolve build issues. You can look at your change again with the command

svn diff -c[revision number]

where [revision number] is the Subversion revision of your commit. Do not include "r" in the command. For example:

svn diff -c23677

If Your Commit Succeeded

Move on to what ever you have to do next. Taunt someone who broke the build recently. Whatever...

-- ScottRankin - 2013-04-09
Topic attachments
I Attachment Action Size Date Who Comment
JenkinsBuildHistory.pngpng JenkinsBuildHistory.png manage 18 K 2013-04-09 - 21:07 ScottRankin A subset of a Jenkins build history.
Topic revision: r7 - 2014-01-27, ScottRankin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback