Automatic Builds of GlueX Software

From GlueXWiki
Revision as of 13:20, 6 June 2016 by Marki (Talk | contribs)

Jump to: navigation, search

Every night a complete build of the source directory is done on several platforms at the lab.

  • The builds are located in the directory /u/scratch/gluex/nightly on the JLab CUE. Everyday a new directory, named by date, is created in this directory, for example, /u/scratch/gluex/nightly/2014-10-03. In the daily directory there is a separate directory created for each platform, e. g., Linux_RHEL7-x86_64-gcc4.8.3.
  • Since the scratch disk cleaning job deletes files unread for more than two weeks, builds older than that cannot be used.
  • The HDDS, and sim-recon packages are built. Latest versions of each are used.
  • The script run is /home/gluex/bin/nightly.sh. It is scheduled as a cron job for the "gluex" account on jlabl1.jlab.org. The job runs at midnight daily.
  • One cron job on jlabl1 runs the builds on the various platforms, as username gluex, serially. The current platforms are:
    • ifarm1102.jlab.org (CentOS 6.5, x86_64, with GCC 4.9.2)
    • jlabl5.jlab.org (RedHat Enterprise Linux 7, x86_64)
  • Log files of the builds are created in the daily directory, for example, /u/scratch/gluex/nightly/2013-10-03/halld_jlabl3.log . For a particular platform, the output of both non-debug and debug builds are in a single log file.
  • A summary of errors and warnings from the last build is available at https://halldweb.jlab.org/nightly/nightly_build_errors.txt . This file is only updated for builds that have errors or warnings. For clean builds, no summary log is produced.
  • The summary of errors and warnings is also sent to the "nightly_build" simple email list.
  • To use one of the nightly builds, you can set up the environment as follows (assume you want to use August 31, 2015):
source /group/halld/Software/build_scripts/gluex_env_nightly.csh 2015-08-31

Note on ssh scheme

As mentioned above although the cron job runs on jlabl1, the builds are all actually done on other nodes. To do this without having to supply a passphrase, the cron job uses a special ssh private/public key pair that only allows the target script on the remote node (and no other command) to run only if the ssh connection comes from jlabl1 and if the target account holds the appropriate public key. This key has no passphrase associated with it[1]and thus can be used from a cron job. The remote target script is only mentioned in the authorized_keys file of the remote account. Only the ssh invocation is seen in the script (/home/gluex/bin/nightly.sh) on the local host (jlabl1).

Note that this special key pair is not the one used for standard ssh connections to gluex account on the CUE. The standard pair has a passphrase. This passphrase-less technique is described in a 2005 Linux Journal article and a CyberSmashup blog article.


Nightly Code Analysis (scan-build)

The scan-build analyzer that uses features built into the clang compiler is run nightly to produce a web report on potential problems identified in the code. Here's some details:

  • Results of the latest analysis can always be found here: https://halldweb.jlab.org/scan-build/LATEST
  • The scan-build program is run via cron job using the gluex account and is run only on ifarm1401
  • The cron job runs the script /home/gluex/bin/nightly-scan-build.csh which is maintained in svn here: https://halldsvn.jlab.org/repos/trunk/home/gluex/bin
  • This piggybacks from the nightly build of sim-recon located in /u/scratch/gluex/nightly/. It requires the setenv.csh script exists for the gcc compiler so that it can source it to get basic things like ROOT, XERCES, JANA, CCDB set up in the environment. (Could be changed to use gluex_env instead and may be done in the future.)
  • This requires the clang compiler. It is currently hardwired to use the 3.7.0 compiler installed in /group/halld/Software/ExternalPackages/clang-llvm/llvm_clang_3.7.0



  1. If it did, then that passphrase would have to somehow be incorporated into scripts, a practice which is generally discouraged for security reasons.