Automatic Builds of GlueX Software
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 .
- 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:
- jlabl1.jlab.org (RedHat Enterprise Linux 6, i686)
- jlabl3.jlab.org (RedHat Enterprise Linux 6, x86_64)
- ifarm1101.jlab.org (CentOS 6.2, x86_64)
- ifarm1401.jlab.org (CentOS 6.5, x86_64)
- lorentz.jlab.org (RedHat Enterprise Linux 6, 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/night_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 October 3, 2014):
setenv HDDS_HOME /u/scratch/gluex/nightly/2014-10-03/hdds setenv HALLD_HOME /u/scratch/gluex/nightly/2014-10-03/sim-recon source /group/halld/Software/builds/nightly/2014-10-03/build_scripts/gluex_env_jlab.csh
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 itand 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.
- If it did, then that passphrase would have to somehow be incorporated into scripts, a practice which is generally discouraged for security reasons.