Contents page for CI validation documentation:
- CI_Validation_Instructions: Instructions for shifters checking CI validation plots. Includes the basics of how to access and navigate the CI validation dashboard.
- Extra tips and tricks for navigating the CI validation dashboard
- Triggering the CI validation
- How to cancel a CI validation
- Checking whether the CI validation has worked
- Finding log files and debugging information if the CI build fails
- Finding output files from the CI validation for further tests
- How to run the CI validation scripts locally
- Full documentation of CI validation scripts: Docdb-13373
Triggering the CI validation¶
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
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>]
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).
You will need to provide the qualifiers (e.g.
e17:prof) for the CI to use when it builds your code, after the
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
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_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.