How to setup and trigger your builds

How to setup the environment

To properly work on the CI system you first need to setup your environment.

NOTE: Before executing the code, move into the directory where you want to put the code

source /grid/fermiapp/products/

mkdir my_ci_dir
cd my_ci_dir

setup generic_ci

git clone
cd glideinwms_ci
setup -. -j glideinwms_ci

if you need to use the test version of the generic_ci you can use:

setup generic_ci -t

if you need to use the latest version of generic_ci that is not yet available as UPS product you can use:

git clone
cd generic_ci
setup -. generic_ci

if you are a developer of glideinwms_ci, to clone the code with write permission you can use

git clone ssh://
cd glideinwms_ci
setup -. glideinwms_ci

The previous code allows you to setup the generic_ci and the glideinwms_ci in the my_ci_dir directory

Tips for a faster setup

The CI environment needs to be configured every time you log into the machine.
If you haven't deleted the folder the first time you configured the CI System, you can avoid to download again the code from the repository and use the same code that is on the machine.
If you plan to use the local build more than once, could be good to setup a function into your .bashrc file.
To do that follow these steps:

NOTE: You need to adapt this to your specific use case.
NOTE: I'm using vim as text editor but you can open the file with your preferred text editor.

  1. Open the .bashrc file with a text editor
    vim ~/.bashrc
  2. Paste the following code to the end of the file: P.S: In vim you need to press "i" to activate the insert mode
    function setup_ci
        source /grid/fermiapp/products/
        cd ${my_path}/generic_ci
        setup -. generic_ci
        cd ${my_path}/glideinwms_ci
        setup -. -j glideinwms_ci
  3. Save the changes and close the file.
    NOTE: In vim you need to press Esc then type ":wq" and then press Enter to save and exit
Once you completed the previous three steps, every time you log into the machine you can setup the CI Environment using one of the following methods:
  1. giving as argument to the function the full path of the my_ci_dir directory:
    setup_ci <path/of/your/my_ci_dir/directory>
  2. Running the function without argument if you first change directory to the my_ci_dir directory
    cd <path/of/your/my_ci_dir/directory>

Manually trigger a CI build

Once the environment is set, you can launch the CI build running the trigger script with different options:
  1. To trigger the default CI build
  2. To trigger a CI build with a specific tag
    trigger --revisions "<package name>@<tag name>"

For the online help page of trigger, use the following command:

trigger -h

For example, you can trigger the default CI build and get it running right away using

trigger --build-delay 0

Workflow configuration

You can look at the details of the workflow configuration here

How to monitor the status of your build

The GlideinWMS_CI Web Application

To monitor the status of your builds into the CI system, our team created an experiment based web application to help you with your monitoring job.

The application can be found at the following link:

This application offer to you all the necessary tools to monitor the status and the performance of your builds in a short and long term.
It offers a quick overview of the status of the last ten builds and offers also dynamic graphs to show the overtime performance of the different build phases.

The main page of the web application

CI System Homepage

The previous image shows the homepage of the GlideinWMS CI web application.

This page is divided into three main sections:
  1. The search and filter section ( on the left of the image )
  2. The legend section ( on the right of the image )
  3. The Show data section (in the middle of the image )

The search and filter section

The purpose of this section is to offer to the user a tool to filter the results shown in the web application.
This panel allows you to:
  • Show the builds up to a defined build number.
  • Show the builds in a defined time range.
  • Filter the builds for platform or for test suite used.

The legend section

This section show the association between the color of the different phases of the builds,and their status
  • [#] yellow -> The phase is running
  • [#] gray -> The phase is pending
  • [#] green -> The phase was successful
  • [#] orange -> The phase failed in warning status
  • [#] red -> The phase failed
  • [#] light blue -> The phase have been skipped
    NOTE: A warning status is when the tests are successful but the product size or names are different when the output is compared to a reference file

The Show data section

This is the main section of the homepage and it's where the most important data is shown.
This section shows a table of the last ten builds executed and their corresponding information.

The table is divided into multiple columns.

The first three columns show some basic information about the CI build number, the time when the CI build started and the platform on which the CI build have been executed.

The next columns show the status of the different phases of the CI build.
Each phase is represented by a square with a bullet

In this moment a GlideinWMS CI build is divided into three phases:
  1. Checkout
    Show the status of the checkout of the code from the repository.
  2. Pylint
    shows the status of the building process of the code into the CI System.
  3. Unit tests
    Show the progress of the CI tests defined for this build.

Dynamic graphs and statistics

Every bullet and the build number into the web application is clickable.
Performing a click on a bullet open a different web page that shows detailed information on the phase.

CI Build Details

Checkout Phase Details

Pylint Phase Details

Unit Test Phase Details