Jenkins is a simple application designed to keep an eye on a series of executions in a software environment. For example – it works like ‘Cruise Control’ and offers a single simple use continuous system for integration. Developers can then execute test cycles more easily and the latest build can be quickly and efficiently delivered to users. One question that users of Jenkins have often raised is how to implement static code analysis in a Jenkins environment.
No built-in support for static code analysis
Jenkins has no facility for static code analysis within the application environment. It’s used for continuous build environments and to keep an eye on jobs running externally from an environment to report on outputs from those jobs. This can be frustrating for developers who would like to use Jenkins for its automation facility but are also looking for the application to assist with the security testing of their code.
It’s OK. Jenkins does support static code analysis from other packages. A plugin is used to capture the results and to parse them. Once these results are passed to Jenkins, the application enables the results to be visually represented in a consistent manner. Jenkins can report on the warnings generated by a build, deliver trend reporting that shows the level of warnings generated by subsequent builds, granular reporting (module, type, package, etc.) for warnings, severity reports, an HTML comparison of source and warnings, stability reporting, project health reporting, scoring for builds that are “warning free”, e-mail reports, etc. There is also support for a remote API so that the plugin can be simply integrated into Jenkins without hours of development time wasted on facilitating that integration.
The good news is that to enable Jenkins static code analysis, leading SCA vendors has an out of the box integration with Jenkins to provide all these reports. Make sure this box is ticked before you purchase and invest in a static code scanner. Stay safe!