Knowledge Base > DCover CLI > Adding DCover to a CI Pipeline

Adding DCover to a CI Pipeline

Adding Diffblue Cover to your CI pipeline means that you can have unit tests automatically generated to check your code quality, saving the time and resources required to write them. This aids developers in their work and has a positive impact on the development schedule. It also forces the developer to make sure they are updating the tests and not passing on any failing tests to other Pull Requests. Using DCover in your CI environment also protects the codebase. The CI pipeline is shown below:

Please watch our demo for more details of using DCover in your CI pipeline.

The instructions below are for a single module project, but can be easily adapted for a multi-module project.

Prerequisite

Ensure your project compiles successfully within a fully-functioning CI pipeline.

Adding DCover to a CI pipeline

Create a new workflow and select the relevant script below, taking care in each case to set:

  • The workflow name
  • Suitable environment variables. These are:
    • The access token for the account that is your CI user (note that this must NOT be a Bot account)
    • The DCover release URL.

The scripts below are self-documented and contain all the details you need for each implementation.

Notes:

  1. The script checks if the Bot made the last commit. This is to avoid a possible infinite CI loop.
  2. The output values are:
    • 0 = the last commit was NOT made by the Bot
    • 1 = the last commit was made by the Bot.

Updating DCover within the context of the CI pipeline:

When a new version of DCover becomes available, create a new baseline set of unit tests as follows so that any changes to tests due to improvements in the software appear in the parent branch:

  • Delete all Diffblue unit tests in the parent branch.
  • Recreate the baseline of unit tests using the new version of DCover.
  • Developers keep their branches in sync with the parent branch.
  • When a Developer submits a merge/pull request, updated tests are created for only their changes.
  • New tests for specific changes get merged back into the parent branch along with code changes.
  • If there are any changes to the code following review, the specific tests can be deleted and replacements created when the CI process runs again.

 

GitHub and Azure

https://github.com/diffblue/cover-pipelines/tree/master/azure-github

GitLab

https://github.com/diffblue/cover-pipelines/tree/master/gitlab-ci

Jenkins

https://github.com/diffblue/cover-pipelines/blob/master/jenkins-github/Jenkinsfile

Please note the following prerequisites for Jenkins only:

  1. Use global credentials (i.e. your GitHub username and token) that have access to the relevant repository.
  2. Ensure the Github pull request builder plugin is selected.
  3. Use HTTPS rather than SSH.