Preparing the release

Release tools

LbScripts can be released with the same tools as for all other projects, but some extra steps are needed for install project.

ALERT! a cached version of the environment is generated, so it is necessary to make sure that you do not have LbScripts in your User_release_area when performing the release.


The LbConfiguration package generates the LbLogin script whichs contains the name of the released version.

ALERT! Therefore, LbConfiguration must ALWAYS be released with the same version as LbScripts itself !

LbLegacy / install_projects specific steps

When releasing LbLegacy, must be updated at each new release of LbScripts in order to make sure that the auto-update mechanism of install_project and LbScripts works correctly. In this scripts the script_version variable must be set to the day of the release with the following pattern: YYMMDD, e.g.:

script_version = '120206'

It should increase monotonously, as install_project uses this variable to check wherther a new version is available.

The LbScripts version should be set to the version of LbScripts to be released as this is used to choose the version to e downloaded from the repository e.g

lbscripts_version = "v6r6p4"

Once all packages have been tagged individually, call:

tag_package -P LbScripts version

Building the release

mkproject -p LbScripts -v vXrYpZ --not-parallel

Setting the new release as the "dev" version

Once the release of LbScripts vXrYpZ has been deployed to the the release area, it is necessary to change the link $LHCBRELEASE/LBSCRIPTS/dev:

rm dev && ln -s LBSCRIPTS_vXrYpZ dev

Switching the production release to a new version

A "prod" symbolic link exists on AFS that points to the production version of LbScripts.

ALERT! When putting a release in production, the link has to be updated by doing:

rm prod && ln -s LBSCRIPTS_vXrYpZ prod

The links should be updated on CVMFS and on local install by install project itself.

Test uses cases

This section provides some (incomplete) information about the scenarios that should be tested when releasing a new version of LbScripts.

Main types of installations: * Single repository: Used for normal installations on a mahine without AFS or CVMFS * Chained repositories: Used for grid jobs which use software from a shared area, but also install software in their local disk space

Main use case: * Install some new software * Add versions/new projects to an existing area * Check whether a project is installed * Check whether the SQLDDDB data package is installed (this is a special case)


Make sure that the account used for testing does not have the LHCb environment already set up ! The variables CMTSITE and CMTPROJECTPATH especially ! For accounts linked to group z5, touch the file ".nogrouplogin" to avoid invoking the group scripts automatically !

A version of LbScripts is needed. For the production version:

For the dev version:

If a version of install_project is already there, it is also possible to use the --dev-install option to switch to the "dev" version of install project.

MYSITEROOT and CMTCONFIG must be defined, e.g.

export MYSITEROOT=/opt/install/lib
export CMTCONFIG=x86_64-slc5-gcc43-opt

N.B. In order to test LbScripts before the release of a new version, it is necessary to invoke LbLogin with the following options:

LbLogin --user-area-scripts --scripts-version=""

Single area

* Install a version of Gaudi and check logs and presence of files

python -b Gaudi v23r4

* Use install project to check that the software is installed

python -b --check Gaudi v23r14

* Check group permissions on repositories (XXX check what they should be)

* Check that --check on SQLDDDB is always false

python --check SQLDDDB

* install Brunel

python -b Brunel v44r0

* Setup the Brunel environment and run the SAM test

. ./
SetupProject Brunel 
cmt TestPackage sam

* Try SetupProject with --use

python AppConfig v3r147
SetupProject --debug --use="AppConfig v3r147"  Brunel v44r0

Chained area

In this configuration, the MYSITEROOT contains several repositories (2 normally) separated by a colon like a PATH.

export MYSITEROOT=/opt/install/joblocal:/opt/install/shared
In this configuration, for the tests to be more realistics, it is necessary to make sure that the test cannot modify files in the shared area (e.g. chaining with cvmfs with give that effect). e.g. using two different accounts on lxplus (with /tmp/lben/siteroot containing the previous installation).

setenv MYSITEROOT '/tmp/benlhcb/LocalArea:/tmp/lben/siteroot'
cd /tmp/benlhcb/LocalArea
python ./ AppConfig v3r146
source ./LbLogin.csh

Check that AppConfig v3r146 is in /tmp/benlhcb/LocalArea/lhcb/EXTRAPACKAGES/

SetupProject --debug --use="AppConfig v3r146"  Brunel v44r0

Run Brunel with a few events $APPCONFIGOPTS/Brunel/ $BRUNELROOT/options/ --option="from Configurables import Brunel; Brunel().EvtMax=10"

The same tests as for a single area should be re-run.


-- BenjaminCouturier - 13-Feb-2012

Edit | Attach | Watch | Print version | History: r32 | r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r10 - 2012-10-08 - BenjaminCouturier
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback