Continuous Integration

Last update: 06 Aug 2024 [History] [Edit]

The historical development workflow based on SVN and tag collector has a few shortcomings. Prominent examples are:

  • You have to make a tag and collect it into a (nightly) release before you can see whether your code changes actually work in the full release.
  • Nightly builds have a fixed schedule which basically gives you one attempt per day and leads to a rather long feedback loop of 24h.
  • Due to many parallel and experimental developments, the development release is often in an unstable state. This makes software development on the development branch a very tedious adventure. And this is certainly not how it should be!

With the switch to git and the usage of a Continuous Integration (CI) system, we hope to improve the situation in several ways. You can think of the CI system as an extension of a nightly system. The difference is that instead of running build jobs at predefined times, jobs are created whenever a new merge request is opened. Every time a new merge request is opened to the main ATLAS Offline Software repository, a CI job is started which performs the following steps:

  1. Checkout your changes and perform the merge locally on the build machine.
  2. Run the cmake configuration step.
  3. Run make to (re)-compile the whole release.
  4. Run some (very) basic tests to ensure that your changes do not break things completely.

Warning Step 3 is not running a full build from scratch (as this would take about 4h for every merge request), but is re-using the build output from a previous build (so-called incremental builds). While in theory this should be safe and dependents of your changes should be re-compiled, this has never been tested inside ATLAS at such a scale. Therefore, be aware of this setup and report any suspicious behaviour you may observe.

Tip ATLAS is using Jenkins as continuous integration system and all jobs are run by the atlasbot user. So do not be surprised if you see comments from this guy on your merge request.

The build and test results are reported on the GitLab merge request page.

The result and logfiles of the build jobs form a central ingredient to the merge review process. As a developer you are of course responsible for checking these results and take appropriate action if needed.

The release name has the format “MR-ABCD-YYYY-MM-DD-HH-MM” where “ABCD” is the GitLab merge request ID and “YYYY-MM-DD-HH-MM” is the time stamp when the build started. By clicking on the number in the “% comp” column you get to the package which lists the build log files for each package. Have a look at them!

The current CI (and Nightly) system features and policies can be found on this twiki page.