Jenkins

Introduction

Jenkins is a freeware java code build system that the Scientific Computing Division is maintaining for the experiments. It runs on several powerful build machines where the code can be built using significant parallelism. It also has many useful management features. You can browse the Jenkins system. and docs for code managers. Jenkins manages and runs build scripts, triggers, archiving and reports, but the actual compilation with scons is black box to Jenkins.

Anyone can view the Jenkins pages, but to edit the pages you need to put in a ticket to get edit permissions in Jenkins, then authorize yourself to the site with a certificate. To edit, the Jenkins page should have your username at the top right. If it says "anonymous", try deleting your "buildmaster" cookies, restarting the browser, check that your cert is loaded in the browser, and try again.

Running Projects

Uses Jenkins for several purposes

1. for Continuous Integration builds. These are triggered automatically
   1. Github PR Tests for reacting to github commits with a build test and few short validation tests
   2. mu2e_muse_ci_build for reacting to a github merge by building Offline and writing it to cvmfs in a special area which can be accessed by "muse setup HEAD".
2. validation.
   1. mu2e-offline-geant-int builds every night to check that the future version of geant is still integrated
   2. mu2e_muse_test checks many aspects of Muse functionality - run by hand when the head of the Muse repo needs testing
3. building code for UPS packages. When a new tag is available these can be run by choosing "run with parameters," entering the tag and options in the project fields and building. The result is a link to a tarball which can be fetched and installed on cvmfs.
   1. mu2e-ADC-build artdaq_code
   2. mu2e-ADCM-build artdaq_core_mu2e
   3. mu2e-BTrk-build
   4. mu2e-KinKal-build
   5. mu2e-pcie-build
   6. mu2e-scons-build
   7. mu2e-TRACE-build
4. building Musings which are sets of code repos built to work together.
   1. mu2e-musing-build see more below.

Most are driven by a set of scripts kept in the codetools repository and UPS product. Below is more information on a few projects.

mu2e-musing-build

This musing build is used to build code with the Muse system, and produce a build tarball, ready to be installed in the cvmfs /cvmfs/mu2e.opensciencegrid.org/Musings area, and setup by the muse command.

1. before running on jenkins
   1. checkout the MuseConfig repo
   2. read the instructions in MuseConfig/musings/README.mk
   3. modify the appropriate file in musings directory
   4. commit and merge (no tags needed, build is from the head)
2. on jenkins
   1. log onto Jenkins system. To do this procedure, you will need to be identified to Jenkins by a cert loaded in your browser before you visit the site. The Jenkins page should have your username at the top right. If it says "anonymous", you are not authenticated.
   2. browse to mu2e tab then mu2e-musing-build project
   3. click in "build with parameters"
   4. enter the musing name and version number
   5. click "build"
   6. check logs by clicking on one of the status balls, then "last build" then "console output".
   7. click into the build and there will be a link to the tarball as the "build artifacts" from the process
   8. grab the link to the tarball
   9. pull the release tarball to the code disk using wget/curl and the CVMFS instructions

Continuous Integration Project

The computing division has written a set of scripts to run inside Jenkins and give additions features, such as timelines, to the build steps. This is called the Continuous Integration Project. We do not use this service at this time.

Trigger by URL

Projects can be kicked off by POST'ing a url with curl.

curl  -X POST "https://buildmaster.fnal.gov/buildmaster/view/mu2e/job/mu2e-BTrk-build/buildWithParameters?token=02345&PACKAGE_VERSION=v1_02_04&COMPILER=e14"

You can get the token (a kind of password) from the configure page. The parameters are also defined on the configure page.

Pushing a cert

To retrieve a file using a cert. Export your CILogon cert as a .p12 file and note the password. Then

openssl pkcs12 -in cilogon.p12 -out file.key.pem -nocerts -nodes
openssl pkcs12 -in cilogon.p12 -out file.crt.pem -clcerts -nokeys    
curl -O -E ./file.crt.pem --key ./file.key.pem \
https://buildmaster.fnal.gov/buildmaster/view/Art/job/build-mu-dist/BUILDTYPE=debug,label1=swarm,label2=SLF6/lastSuccessfulBuild/artifact/copyBack/cetlib-3.01.03-slf6-x86_64-e15-debug.tar.bz2

Push a cert with a url that triggers a project, so the jenkins project can use it.

# I assume that X509_USER_PROXY points to an existing proxy path
# in the 'mu2e' Jenkins project used in the link below you need
# to define a "Password Parameter" variable named: MU2E_CREDENTIAL


# on your local node:

~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~
credbits="MU2E_CREDENTIAL@$X509_USER_PROXY"

val2="value2"

curl -f \
--data-urlencode "token=1234" \
--data-urlencode "var1=value1" \
--data-urlencode "var2=$val2" \
--data-urlencode "$credbits" \
https://buildmaster.fnal.gov/job/mu2e/buildWithParameters
~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~

# I assume your Jenkins project is named "mu2e", replace that bit for different Jenkins projects
# var1 and var2 need to be defined in the Jenkins configuration to be able to retrieve their value
within a Jenkins job

# In your Jenkins job script to retrieve the proxy you can do the following:
~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~

export X509_USER_PROXY=/tmp/$$.proxy

rm -fv $X509_USER_PROXY
touch $X509_USER_PROXY
chmod 0600  $X509_USER_PROXY
echo "${MU2E_CREDENTIAL}" > $X509_USER_PROXY

voms-proxy-info -all

~~~8<~~~~~~~~~~~~~~~~~~~~~~~~~