Continuous integration

Continuous integration (CI) is the process of continually merging different feature branches into the main branch1 and automatically triggering software tests2 or the overall software build process to help ensure software stability during the development process. CI provides continual feedback on potential issues that may have been introduced during development of new features so they can be addressed before a merge into main. For more information about this process, you can read overviews from Atlassian or Wikipedia.

Continuous integration is often paired with the code review process, where software integration test suites are run during a pull-request/merge request, and the reviewer will only sign-off on merging code into the main branch on successful execution of the test suite.

Both GitHub and GitLab provide the capability of triggering tests (or other code) during the initiation of a pull-request and informing reviewers if these tests have passed or failed as part of the pull-request/merge-request. This is accomplished via GitHub Actions and GitLab Pipelines.

GitHub Actions

GitHub Actions is GitHub’s method for triggering code (including software test suites) under a variety of condutions, such as initiation of a pull-request. In general, GitHub Actions are controlled by YAML-formatted files under the .github/ directory in your git repository.

Triggering test suites in GitHub

Depending on the programming language you are developing with, there may already be templates and guides on how to setup GitHub actions for running test suites. There are existing repositories for R actions and a guide for Python actions.

GitLab Pipelines

GitLab CI/CD provides a similar service as GitHub Actions for GitLab. That is, GitLab CI/CD can be used to trigger commands to run under different conditions (such as creating a merge-request), which can be used to run software test suites. The results of these test suites are shown within a merge-request to indicate to a reviewer if the updated code passes all the necessary tests.

In general, the execution of GitLab CI/CD commands is configured via a .gitlab-ci.yml file within your git repository specifying the commands to run. This defines different GitLab Pipelines to run, which consist of collections of jobs to run during different stages. These are run using runners in GitLab. Please see the GitLab CI/CD documentation for details on terminology.

Footnotes

  1. This technique builds upon branching and our recommended git workflow.↩︎

  2. Like unit tests↩︎