Continuous Integration

Continuous integration means that changes in a software are frequently committed to a shared repository. This has many advantages such as detecting errors sooner, less possibilities for conflicts and others. For a more detailed explanation it is recommended to take a look at the corresponding GitHub page.

In order to avoid the introduction of errors from the commits, the code is continuously checked. This can include compiling, testing, but also other things like linting or code coverage checks.

In Kratos every pull request has to pass a set of tests in order to be merged. Those checks are the compilation and testing of the Core and several Applications on different systems (e.g. Linux, Windows) with different compilers (e.g. MSVC, GCC, CLANG, Intel).

If a required check fails, the pull request cannot be merged, even if it was approved!

Most of these checks are done with Github Actions. It is a (for open source projects) free service provided by GitHub to automate tasks related to software development.

Current configurations

Different configurations are compiled and tested, e.g. with GCC and CLANG under Linux and MSVC under Windows For details please check the actions configuration files in the workflows folder

CI check before merging pull requests

Opening a pull request automatically triggers the checks. Their status can be seen either at the end of the page or in the Checks tab. There all the configurations are listed. Each check has several steps (e.g. building, testing). The current status of each check can be observed by clicking the corresponding step.

If a step fails, the following steps also abort and the check didn't pass. If the check is marked as required then it must pass before merging is possible. By checking the log of the failed step the error can be seen.

Note that the "small" suite of the tests is run in the CI (max runtime: 1 min per Application, if it takes longer the test will be passed and marked as failed)

Nightly build

In addition to the CI builds, the nightly build runs every night with a different test suite, namely the "nightly" suite. Those tests can take up to 15 min per Application.

Note that the status of the nightly build is also shown with a badge on the main page of Kratos. Hence failing nightly builds will have a negative effect on the reputation of Kratos and must be fixed as soon as possible.

Rules for adding an application to the CI

For adding a new application to the CI, the Technical Committee decided that the following is required (see here):

• The Application must have tests
• Having at least two maintainers providing continuous support in case of CI failure. In case of no support the application would be removed from the CI.
• There are timers which limit the testing time for each applications (1 minute per Application for small tests, 15 minutes per Application for nightly tests). So the total CI time cannot be abused by one application. Please note that the CI machine is considerably slower than a normal desktop.

So applications which want to be part of the CI can create a PR adding the application to it. These PRs should be approved by the Technical Committee.

FAQ

• How to restart a build? https://docs.github.com/en/actions/managing-workflow-runs/re-running-a-workflow

• How to check a branch without opening a pull request https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow => currently supports CI and Nightly Build

• Cancelling (redundant) builds is done automatically (i.e. if a newer commit is pushed before the checks of the previous commit finished)

• For canceling workflow manually check here: https://docs.github.com/en/actions/managing-workflow-runs/canceling-a-workflow

• Viewing logs: https://docs.github.com/en/actions/managing-workflow-runs/using-workflow-run-logs

Possible future extensions:

• Add MacOS build
• Add build with Intel compiler
• Runs tests with Valgrind
• Use Sanitizers
• ...

Further information (not only for developers)

• Where to find the files? here
• Reference Documentation
• Supported runners and hardware resources
• Supported software