This quickstart explains how to set up a Jenkins multibranch pipeline to run a Coverity full scan and Pull Request scan for branches in a repository. The quickstart explains how to achieve this for languages with and without a build system such as make or Maven.
The full scan will be triggered by push and merge events on specified branches. Full scan issues that violate a policy view will be uploaded to a Coverity Connect instance as a snapshot within a stream. Conversely, the Pull Request scan will be triggered by push events to Pull Requests that target specific branches. Pull Request review comments are only created for new issues created that are detected on the feature branch but not the target branch.
Prerequisites
- The following reading is recommended before starting the quickstart:
- Install the Black Duck Security Scan plugin to integrate with a Coverity Connect instance.
- Install and configure the appropriate Branch Source plugin to enable Jenkins to integrate with a source code repository and validate pull request events.
- Configure a source code management token to enable the Black Duck Security Scan plugin to inject Pull Request review comments for new security issues uncovered during a Pull Request scan.
- Access to a Jenkins Multibranch Pipeline project.
- Warning: Please note that the following Black Duck Security Scan Plugin parameters are required to run a Pull Request scan and inject review comments. These are included in this quickstart example and listed in the table below. A Pull Request scan will not run if these parameters and quickstart prerequisites are not configured. This includes providing a source code management token to allow review comments to be added by the plugin.
Parameter Description Example coverity_project_nameThe name of the Coverity Connect project. "$REPOSITORY_NAME"coverity_stream_nameThe Coverity Connect stream name that stores scan snapshots. "$REPOSITORY_NAME-$BRANCH_NAME"coverity_prComment_enabledWhen true, this enables Pull Request comments."true"Note: The Black Duck Security Scan Plugin integrates with Coverity via Bridge CLI. Additional scan configuration options not available through the template's parameter set can be specified by defining relevant Bridge CLI environment variables within the workflow job. - Coverity requires additional configuration for compiled languages. For languages that use a build system (such as C++, Java, etc.), Coverity must be configured with build and clean commands to capture and analyze the build.
- The instructions below use pipeline parameters to specify build and clean commands.
- See Using Bridge With Compiled Languages for an explanation of the various methods available for configuring Bridge to integrate with Coverity to capture and analyze the build for compiled languages.
Instructions
Troubleshooting and support
If a pipeline error is encountered similar to the example below, then the
coverity_local parameter should be uncommented in the quickstart code example.Attention: ERROR: Failed to retrieve tool information details: Fetch tool information: received unexpected response status code '500' from Connect API
In this scenario either scan services are not enabled or a Coverity version prior to 2022.3 is deployed. The default behavior is that the pipeline uses the Coverity thin client to upload artifacts, with the analysis performed at the server. Setting the coverity_local parameter to true enables the full analysis at the client. Subsequently, the scan and analysis will be performed locally on the Jenkins build agent. For further details relating to the different Coverity deployment models supported, please refer to Coverity Deployment Architecture.