The historical development workflow based on SVN and tag collector has a few shortcomings. Prominent examples are:
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:
cmake
configuration step.make
to (re)-compile the whole release.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.
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.