Configuration
Last updated
Last updated
There are three key components for configuring Cover Pipeline for GitHub:
Labels: Pre-defined Diffblue Cover repository labels to determine test requirements on pull requests (full baseline, update, or skip).
Environment Config: Direct license key and access token config.
Workflow Config: Configure the Diffblue Cover section of your workflow including Cover version, build config, and Cover commands to execute on pull requests.
Note that the Quick Start - General describes how to configure Diffblue Cover in CI without using the Diffblue Cover Pipeline Action. Further details on appropriate environment configuration that can be used in GitHub CI can also be found in Environment configuration for CI.
When writing tests, Diffblue Cover will respond to specific repository labels:
Diffblue Cover: Baseline Used to mark a pull request as requiring a full suite of tests to be written. This overrides the default behavior where Cover will only write tests related to the code changes already in the pull request. The baseline label is applied automatically when running Diffblue Cover for the first time on a project (to create the initial baseline test suite). On subsequent runs, you can select this label within a pull request, if required - useful when you want to refresh your entire test suite, such as when new product enhancements are released (to update the entire test suite with the latest enhancements).
Diffblue Cover: Skip Used to mark a pull request as requiring no tests to be written. The skip label is useful when performing pull requests that have no impact on unit tests, such as updates to comments only.
These labels are created automatically in GitHub when running Diffblue Cover for the first time on a project, and can be selected as part of the pull request as needed.
To configure the Diffblue license key and associated GitHub access token and permissions:
In GitHub, go to Settings > Secrets and variables > Actions > Repository secrets
Add a New repository secret and set Name to DIFFBLUE_LICENSE_KEY
and set Secret to your Diffblue Cover license key (see Licensing, if needed).
Add another New repository secret and set Name to DIFFBLUE_ACCESS_TOKEN
and set Secret to the GitHub access token used to allow Diffblue Cover to access your project. In general, use a GitHub Classic access token with full repo
permissions. For more information on GitHub access tokens, see the GitHub access tokens docs topic.
Optional: For offline license activation please add another New repository secret with Name set to DIFFBLUE_OFFLINE_LICENSE_ACTIVATION_FILE_CONTENTS
and Secret set to the contents of your offline license activation file ls_activation.lic
. This will then need to be passed through to the Diffblue Cover Action workflow as shown below.
Finally, make sure that your repository allows actions to be executed - in the repository go to Settings > Action permissions:
Note that GitHub fine-grained access tokens are in Beta and not supported. If you must use a fine-grained access token then the following are required:
Contents: write
Pull requests: write
Using an access token with excessive permissions is a security risk. If you use a Personal access token, consider creating a dedicated user with access limited to just the project, minimizing the impact of the token being leaked.
Update or create a workflow YAML file for your project to configure the Diffblue Cover section of your CI/CD pipeline. Copy the contents of the Diffblue Cover Action workflow available from the GitHub Actions Marketplace (sample below) to your project YAML file, and update if needed. Configurable properties are listed below - for everything else, please leave these set to the values defined in the Diffblue template.
Run Diffblue Cover
uses:
Select the version of Diffblue Cover to use in your workflow. Tag variations are provided for each supported JDK version - see https://github.com/diffblue/cover-github-action/ for details. To use the latest version of Diffblue Cover, use one of the @main
tags. To use a specific release version, use one of the @yyyy.mm.dd
tags.
Run Diffblue Cover
working-directory:
This can be used to specify a different location in the repository to run Diffblue Cover.
Run Diffblue Cover
args:
Diffblue Cover commands and options to run. Default arguments are shown commented out in the template:
ci
– enable the Diffblue Cover Action.
activate
- activate the license key.
build
- build the project using standard Maven or Gradle commands.
validate
- remove non-compiling and failing tests.
create
- create new tests for the project.
Additional optional arguments can be used with the various commands - see Commands & Arguments for details. Note that Cover Reports arguments are not currently supported for use with Cover Pipeline for GitHub.
For reference, the default Diffblue Cover Action workflow is provided below (uses the latest version of Diffblue Cover and JDK 17) . Note that this is a sample only - use the files provided in the GitHub Marketplace Diffblue Cover Action to ensure that you have the latest version.
Diffblue Cover log files are saved to a .diffblue/
directory in the pipeline artifacts (as defined in the workflow YAML file), and are available for download once the pipeline workflow completes. These logs include user logs (also output during the run and visible in the job output) and support logs (if you ever require Diffblue support).