Project

General

Profile


Contents page for CI validation documentation:


Triggering the CI validation

Most of these instructions are taken from the lar_ci wiki instructions about how to set up the CI environment and how to trigger the CI.

How to trigger a CI validation build: the basics

The easiest way to trigger a CI validation build is to use the pre-written scripts located in /uboone/app/users/uboone_ci:

For MC:

sh /uboone/app/users/uboone_ci/run_mcmc_ci_mcc9tag2.sh --revisions <repository>@<branch_or_tag_name> --quals <qualifiers> [-e prev_uboonecode_version=<comparison_branch_or_tag_name>] [--build_delay <delay_in_seconds>]

For data:

sh /uboone/app/users/uboone_ci/run_datadata_ci_mcc9tag1.sh --revisions <repository>@<branch_or_tag_name> --quals <qualifiers> [-e prev_uboonecode_version=<comparison_branch_or_tag_name>] [--build_delay <delay_in_seconds>]

The CI can run validations based on any feature branch or tag in the redmine repository. All you have to do is supply the name of the repository (for example: uboonecode, ubreco, ubana etc...) and the tag or branch name after the --revisions tag. Since uboonecode has been split, you may need to include feature branches on multiple repositories. You can supply as many repository names and tags as you like (in a comma-separated list, surrounded by double quotes "), and you can also use the * wildcard. Note that the code will take the first match to any given repository, and ignore other matches. That means that, for example, if you give --revisions "ub*@v07_02_00,ubutil@v07_00_00", it will match the ubutil repository to ub*@v07_02_00 and ignore the second match ubutil@v07_00_00. To make sure you don't have problems, always put the * wildcard arguments last in the list. If you do not specify a tag or branch for a given repository, the CI will check out develop for that repository (this may cause problems if your feature branch is not compatible with develop of another repository).

For example, all of the following are acceptable arguments:
  • --revisions "ubutil@v07_00_00,ub*@v07_02_00"
  • --revisions ub*@v07_00_00
  • --revisions ubana@feature/my_test_branch

You will need to provide the qualifiers (e.g. e17:prof) for the CI to use when it builds your code, after the --quals tag.

The argument with the -e tag is optional, and defines the "previous uboonecode version" that is used for the comparison plots produced by the CI validation. By default, the CI system will produce comparison plots to the "previous" version of uboonecode, defined as the last version that the CI processed. If you want to compare to a specific base release, all you need to do is give the tag name here. Note that this tag/branch must already have been processed by the CI. You can check if the release has been processed by the CI by looking for the file /pnfs/uboone/scratch/users/uboone/ci_validation/data_mc_cosmic_validation/*/${UBOONECODE_VERSION}/mergeana_MC/ana_hist_MC_merged.root.

If the release you want to compare to hasn't been processed by the CI, you will need to submit a command to process the base release first, and then you can submit your branch. This is where the argument with the --build_delay tag comes in! It is also optional, and can put in an artificial delay on a CI job. This means that you can submit the job for the base release and your feature branch at the same time, and just put a delay on the CI for your feature branch. That way, by the time it comes to make the comparison plots it should already have processed the base release and be ready to compare! If you do not give this argument, the default value is 0 (no delay).

For example, if I wanted to compare v07_02_00 to v07_00_00 and neither had ever been processed by the CI, I could submit the following two commands:

sh /uboone/app/users/uboone_ci/run_mcmc_ci_mcc9tag2.sh --revisions ub*@v07_00_00 --quals e15:prof
sh /uboone/app/users/uboone_ci/run_mcmc_ci_mcc9tag2.sh --revisions ub*@v07_02_00 --quals e15:prof -e prev_uboonecode_version=v07_00_00 --build_delay 1000

What the script does

The first thing the script does is check whether you have the lar_ci ups product already set up. If you don't, it will set it up for you and prompt you for your kerberos password so that it can generate a grid proxy for you.

It will then check the arguments given to it, and call the command to trigger the CI. You can read the documentation about this command on the lar_ci wiki. The script will print the command it is using to the screen so that you can check it.

At this point you'll get a printed message to screen ("Triggering CI build"), but nothing else. You can check the command has worked by checking the CI validation webpage (or see this page for more tips on how to check you have successfully triggered a CI validation build). You will also get an email from Jenkins Slave user, but this can take a little while to come through.