Continuous Integration Project¶
- Table of contents
- Continuous Integration Project
- CI components
The Continuous Integration Project system provides integration builds of software code and reports on current and past builds, along with detailed information on pre- and post-install tests of the software.
If you would like to be on-board in the CI system, please see here.
You don't need anything special to take advantage of the system; if you merge changes into your repository monitored by the CI, you will automatically trigger a continuous_integration build, and you can check the results at the reporting website (see for example NOvA CI monitoring link).For more information about:
- the CI information available, see an annotated Test_result_display example.
- the database schema used to store CI information, see this Database_schema document.
There are five stages to the standard CI workflow: checkout, build, unit-tests, install, ci-tests,
with the addition of an 'eval' phase where the CI sets up the environment for the workflow on Jenkins.
How to request a CI Instance for an experiment¶
To be on-boarded on the Continuous Integration service, follow the guide below:
Requesting a CI Build¶
The whole 5-stage series of events is kicked off by Jenkins upon receipt of a trigger. See Triggering_Builds, particularly if you're a coordinator who wants to learn to fire off experimental workflows/builds. The result is a grid of dimension 5 by
Np at Reporting Website, where
Np is the number of platforms on which the build takes place. Three of the stages which the user may care about are elucidated below.
The checkout stage produces output which can be accessed by clicking on the appropriate box on the grid. Build summary text is at the bottom, showing the unique hash of each of the repositories at this instant, ensuring a reproducible build. More can be learned about the changes to the code in this build by clicking the Change List link there, which takes you back to the Jenkins page and a nicely formatted repo-by-repo summary of the pushes since the last build.
Pre-Install (or Unit) Tests¶
Stand-alone unit tests are written to use only libraries within a particular package. They are generally simple tests that exit with non-zero status if some simple unit of execution gives a non-standard result.
Click on the "make_test" boxes to see the summary.
More useful, in some meaningful ways, are tests which allow the user to see if actual runtime properties are as expected. See Test_Runner_Introduction for much more information. The power of these tests is that all the libraries of the install are now at one's disposal, unlike with the above unit tests, and that means the
experiment binary can be used and modules can be exercised. Click on the "ci_tests" boxes to see results; example output is at ci_tests. And, again, click here to learn what CI tests are running now.