Most pipelines have some version of an “analysis” stage for doing things such as gathering code metrics, determining complexity, identifying bad coding practices and likely breaking points, and calculating potential resource costs such as technical debt. These analytics identify potential problems (some more serious than others), and fixing these “holes” can enhance key characteristics of the code such as readability, reliability, and maintainability.
In this chapter, we’ll look at how to integrate one of the most popular of these applications, SonarQube, into a Jenkins pipeline. We’ll also see how to integrate a separate tool, Jacoco, for code coverage analysis. Code coverage analysis is frequently integrated into a tool like SonarQube, but it’s worth understanding how to separate it out, given the important role that code coverage can often play in analyzing code.
For SonarQube, we’ll start by briefly discussing the tool and how it is integrated into a traditional pipeline. Then we’ll look at how that translates into a pipeline-as-code environment. Along the way, we’ll cover one of the most important aspects of using such a tool in a pipeline, as a way to pass or fail your pipeline stage based on selected thresholds set within the application.
Though we’ll utilize Gradle again here as a supporting technology, the approaches we use should be adaptable to most other technologies once you understand the basics.
Likewise, for Jacoco, we’ll ...