The procedure described here generally follows the method used by larsoft (refer to larsoft instructions here).

The steps are described below.

Check out all uboone suite packages

Log in to your own account on one of the uboonegpvm's (or any other compatible computer) and set up the standard MicroBooNE software development environment. Make a new mrb test release against an existing larsoft base release. Check out all uboone suite packages.

$ source /cvmfs/
$ mkdir <some empty directory>
$ cd <some empty directory>
$ mrb newDev -v <larsoft-version> -q <larsoft-qualifiers>
$ source localProducts*/setup
$ mrb g uboone_suite

For the record, here is the full list of packages that belong the uboone suite in approximate top-down dependnecy order.


Create a working branch for each checked out package

Visit each checked out package and check out or create a working branch. There are several ways of doing this.

  • If this is a regular integration release, and you know that this package needs a new version and what the new version number will be, you can use git flow to make a release branch.
    git flow release start <version> [<existing branch>]
  • Check out an existing branch, such as a production branch, to be updated and/or tagged directly.
    git checkout <existing branch>
    git pull
  • Create a new temporary or permanent release branch off of the head of an existing branch or existing tag.
    git checkout <existing branch or tag>
    git pull
    git checkout -b <new branch>

Make updates and do an initial test build

If there are unmerged feature branches or other branches containing updates, including "team" branches provided by larsoft, merge them now. Update each checked out package's product_deps file to make any required updates due to new versions and/or new qualifiers of external products, larsoft, and/or cetbuildtools. Do not update uboone suite package versions yet. Here is a list of packages that may need updating.


If only the version number (as opposed to qualifiers) needs to be changed, you can use command "mrb uv" to make all required updates to all checked out product_deps files.

mrb uv <package> <version>

A script is available for making most larsoft-related version updates, which script is invoked as follows: <version> -q <qualifiers>

The qualifier argument should include the base qualifier (e.g. e17 or c2), the build type (debug or prof), and the set qualifier (e.g. s91).

It is a good idea to update the larbatch version. Usually, the larbatch version should be the latest built version (available in larsoft cvmfs).

mrb uv larbatch <version>

After all such updates, do a full build-and-test.

$ mrbsetenv
$ mrb t -jN

If there are errors at this point, fix them before proceeding.

The test build can be skipped if you are confident that the build will succeed.

Update uboone suite versions and do a final test build

Visit each package again, starting with low-level packages and ending with uboonecode. Update version information in each package's product_deps. Any package that has its own updates will of course need a new version. Also, any package that has had lower level dependencies changed will need a new version because of modifications to its product_deps file. Use command "mrb uv".

$ mrb uv <package> <new version>

A script is available for making most uboone-related version updates, which script is invoked as follows: <version>

If a package does not have any updates (and therefore doesn't need a new tag), move it away from $MRB_SOURCE.

mkdir ../notag
mv <package> ../notag

Visit uboonecode's releaseDB source directory, and update version information in CMakeLists.txt to match the just-updated version information in product_deps.

$ cd $MRB_SOURCE/uboonecode/releaseDB
<update CMakeLists.txt>

If version updates were made using "mrb uv," as opposed to editing product_deps manually, this step is already done.

After making all updates, and after removing unneeded packages from $MRB_SOURCE, update the master CMakeLists.txt and do another full build and test.

$ mrb uc
$ mrb z
$ mrb zi
$ mrbsetenv
$ mrb t -jN

Again, if there are errors, they need to be fixed before proceeding.

Commit changes and make tags

For each package that is still checked out in $MRB_SOURCE, commit changes make a tag on the working branch. If the working branch is a temporary branch, merge changes to a permanent branch. Push updated branches and the newly created tag, to the main repository. More detailed instructions for specific cases are given below. Note at this point you should never push updates to the develop branch to the main repository.

  • If the working branch was created using git flow release start, use git flow release finish.
    $ git add <modified files>
    $ git commit
    $ git flow release finish
    $ git push origin master
    $ git push --tags
  • If the working branch is an existing permanent branch from the main repository (such as a production branch), or if the working branch needs to become a permanent branch of the main repository, update, tag, and push that branch.
    $ git add <modified files>
    $ git commit
    $ git tag -a -m<version> <verstion>
    $ git push origin <branch>
    $ git push --tags
  • If the working branch is a temporary branch created off of the head of develop (not using git flow), merge updates to the master branch, then tag and push master.
    $ git add <modified files>
    $ git commit
    $ git checkout master
    $ git merge <working branch>
    $ git tag -a -m<version> <version>
    $ git push origin master
    $ git push --tags

Upload build config to SciSoft

Upload files from final test build (after all version updates) to SciSoft.

$ cd $MRB_BUILDDIR/uboonecode/releaseDB
$ copyToSciSoft uboone-*

Uploaded files should include build config (uboone-cfg-<version>) and build instructions (uboone-<version>.html). Note that buildFW requires the build config file to be available in SciSoft prior to the build.

Do Jenkins build

Use the buildFW version of the uboone Jenkins build project, namely, uboone-release-build2.

Upload built packages to SciSoft

Do this step from your personal account in an empty directory.

  • Fetch build artifacts (tarballs and manifests) of any built pacakges using copyFromJenkins. Add "-q" options (repeatable) for any qualifiers that are part of the build matrix.
    copyFromJenkins -q e15 -q c2 uboone-release-build2
  • Upload tarballs and manifests using copyToSciSoft.
    copyToSciSoft *

Install built packages in /grid/fermiapp

Log into account uboone on any uboonegpvm computer.

Check available quota in /grid/fermiapp.

quota -g -s -m

Fetch all updated packages using pullProducts. Do this for each available os, qualifier, and build type.

pullProducts /grid/fermiapp/products/uboone slf6 uboone-06.82.01 e15 prof

All supported binary flavors can be installed using script, which is available when you log in as uboone. This script is invoked with one argument, which is the name of the scisoft distribution bundle. uboone-06.82.01

Upload build packages to cvmfs

After updating /grid/fermiapp, sync to cvmfs using script


Final steps

  • Do final merges.
    If this is a weekly integration release, merge updates from master to develop for each updated package, and push to the main repository.
    $ git checkout develop
    $ git merge master
    $ git push origin develop

    If this is a hotfix release, make sure that any hotfixes are also applied to the head of whatever branch is being fixed.
  • Create a suite tag UBOONE_SUITE_<version> for each package that is included in the uboone suite (whether updated or not).
    git checkout master  # or production branch.
    git tag -a -m"Uboone suite vxx_yy_zz" UBOONE_SUITE_vxx_yy_zz
    git push --tags
  • Update uboonecode release notes on the uboonecode wiki.
  • Send announcement.