Continuous Integration Process

We are using GitHub Actions as CI server solution (see here for more information).

Build and Tests

Whenever commits are pushed to a branch of the main repository or Pull Requests are created or changed, GitHub Actions triggers a new job that builds and tests the state of the updated branch. During the test phase, only the JUnit tests (excluding STF tests) are executed.

See configuration build.yml.

Static Code Analysis

Codacy

The static code analysis is executed for each commit and Pull Request to scan the code and binaries. This scan only looks at the changes made by the pushed commits, meaning it will not analyze existing/unchanged code. The results of the analysis are available through the GitHub interface or can be viewed using the Codacy web interface.

Configured in the admin interface of our codacy project.

PMD

We use the checker tool PMD for analyzing our Java code. PMD is executed by Codacy, but the configuration is located in our repository and Codacy only uses the version on the master branch. Therefore, we execute PMD in a workflow if a commit is pushed or a Pull Request is opened (or updated) that changes the configurations.

See configuration build_pmd.yml.

STF

The STF test execution is triggered for each push to the master branch and each branch with the prefix pr/stf/. Furthermore, it is possible to manually trigger the STF workflow with:

  • Open the project’s Actions tab (with the selected workflow STF Tests).
  • Click the drop-down button Run workflow.
  • Select a branch.
  • If needed, add arguments that are handed to run_stf.sh. If you want to run the STF self tests (located in stf/test) that test the framework (and are not intended to test Saros) add the argument --self.
  • Click the button Run workflow

See configuration stf.yml.

Java 11 Compatibility

We build Saros every week with JDK 11 to verify that the project is still compatible with JDK 11.

See configuration build_jdk11.yml

Documentation

All documentation changes (via pushing a commit or opening a Pull Request) trigger a build of the Jekyll documentation. If these changes are pushed to the master branch, the result is published as new website.

See configuration build_doc.yml