1.说明：Coverity代码扫描工具可以扫描java，C/C++等语言，可以和jenkins联动，不过就是要收钱，jenkins上的插件可以用，免费的，适用于小的java项目
2.这是Coverity的github地址 https://github.com/jenkinsci/coverity-plugin
3.以下是coverity在jenkins上操作 jenkins=詹金斯
安装插件使用插件管理器,重启詹金斯。
Coverity配置工具(管理詹金斯>全球工具配置)
添加Coverity静态分析工具:
添加一个或多个工具,为多个平台配置工具可以在这里管理。 命名为“默认”将优先的工具,否则可以配置工具路径(或重写)每个节点和/或工作配置。
注意:在詹金斯詹金斯2之前,全球的工具配置系统
配置Coverity全局设定(管理詹金斯>配置系统)
Coverity连接实例添加连接细节
将证书添加到存储Coverity连接用户名和密码(通过管理凭证插件)。 Coverity插件仅支持“用户名与密码”证书。
点击检查验证您的设置和Coverity用户账户权限
配置节点的特定工具(如果需要)
如果喜欢,可以覆盖默认的工具路径通过设置工具位置节点配置设置
使用的工具也可以配置每个任务配置(或重写)如果这对分布式构建更有效的体系结构
从头开始创建工作,通过创建或复制从现有的工作。
下构建中,选择添加构建步骤并选择调用Coverity捕捉构建,如果必要的。
如果没有提供调用Coverity捕捉构建,Coverity插件将透明地调用构建捕获所有构建步骤在您的构建。
下Post-build行动中,选择添加post-build行动并选择Coverity。
选择Coverity连接实例,项目和流相关的这份工作。
如果你想要的插件调用cov-build / cov-analyze / cov-commit-defects给你,请检查执行Coverity构建、分析和提交。 您可以添加额外的参数为每个这些工具,使用和配置中间目录(可选)。
如果您的构建已经调用Coverity,放任的复选框。
如果你想失败构建当缺陷被发现时,检查对应的复选框。 默认情况下所有缺陷被认为是,但您可以指定过滤器。 每个过滤器都应该匹配一个缺陷被包括。
如果你想要这个插件调用测试和测试顾问功能,检查执行Coverity测试顾问和提交。 您可以添加额外的参数和功能构建通过输入您的源代码控制(可选)配置。
构建完成后,链接Coverity缺陷可以在构建页面。
在项目页面,图与历史缺陷计数是可见的(只要超过一个构建已经完成)。
访问Coverity插件配置对话框,首先选择一个项目在詹金斯服务器,并选择配置。 Coverity-specific设置下是可用的构建和Post-build行动部分。
Coverity构建操作有以下选项:
选项描述
构建器选择将包裹的构建步骤cov-build。 注意,如果Coverity捕捉构建步骤不是添加,然后构建步骤都是包装。
Coverity post-build行动有以下选项:
选项描述
检查配置点击确认Coverity连接的连接到一个流是正确配置。
Coverity连接实例Coverity连接实例选择(从全局配置)。
项目项目包含流和获取缺陷。
流流和获取缺陷。
缺陷的过滤器选择显示缺陷分类、行动、严重程度、影响,组件,检查器,或日期首次检测到。
执行Coverity构建、分析和提交当这个选项被选中时,使用cov-build詹金斯将监控建设,运行分析,并提交缺陷Coverity连接。 各种参数可以指定优化构建过程。
执行Coverity测试顾问和提交设置测试顾问配置,覆盖配置设置特定于C / c++, c#和Java。
源代码控制配置“供应链管理”(可选)作设定,使检索源代码控制的版本历史。
失败构建如果找到匹配的缺陷构建失败如果缺陷发现通过过滤器的所有缺陷。
如果找到匹配的缺陷构建标记为不稳定构建标记为不稳定如果缺陷发现通过过滤器的所有缺陷。
构建后不获取缺陷吗选择这个如果构建缓慢或获取缺陷太多资源。
保持每个构建后中间目录构建后保持中间目录。 这只会产生影响是一个非默认选择中间目录。
隐藏的缺陷图在项目页面隐藏的缺陷图在项目页面。 这个设置可以加快页面加载时存在大量的缺陷或构建。
Coverity先进解析
Coverity插件的基本支持一些管道功能。 (https://jenkins.io/doc/pipeline/steps/coverity)
它提供了一个withCoverityEnv一步调用和包装工具coverityResults一步从Coverity连接视图检索问题。 为了使用这些步骤你需要设置Coverity工具在全球工具配置和全球配置(见Coverity连接实例开始详情)。
这个步骤将使用指定的Coverity工具安装和bin /目录添加到路径包裹的任何步骤。 这将允许管道脚本访问Coverity工具(如cov-build、cov-analyze和cov-commit-defects)直接从脚本步骤(如一个Shell脚本或Windows批处理脚本)。 同时,这个步骤提供了用户绑定Coverity连接实例信息,如主机/端口/凭证环境变量。
建议用法:
withCoverityEnv(coverityToolName: ‘default‘, connectInstance: ‘Coverity Connect Instance Name‘) {
// execute any coverity commands with either `sh` or `bat` script step
// (all Coverity Tools in /bin available on PATH)
// By default, Coverity Connect Instance information will be avaible in following environment variables
//
// HOST -> COVERITY_HOST
// PORT -> COVERITY_PORT
// USER -> COV_USER
// PASSWORD -> COVERITY_PASSPHRASE
//
// Users can customize all the above default environment variables
}
这将使用Coverity静态分析工具安装名为‘默认’和‘/ bin目录添加到路径范围内构建包装。
提示:使用管道语法片段的发电机withCoverityEnv确保你选择一个配置工具的安装和配置Coverity连接实例
用一个变量在脚本访问coverity工具目录中,例如:
def covHome = tool name: ‘default‘, type: ‘coverity‘
sh "${covHome}/bin/cov-build --dir idir <build-command>"
// followed by other coverity commands (using "${covHome}/bin")
手动更新env。 脚本的路径
env.COV_HOME = tool name: ‘default‘, type: ‘coverity‘
env.PATH="${env.COV_HOME }:${env.PATH}" // on windows node use ;
sh "cov-build --dir idir <build-command>"
// followed by other coverity commands (all in /bin available on PATH)
你也可以把withEnv与tool一步Coverity工具目录设置为任何环境变量
工具目录将解决的节点执行管道(见开始有关工具安装和每个节点位置)
注意,对于任何Coverity工具执行构建/分析/提交步骤必须共享相同的中间目录值(见Coverity分析用户和管理员指南更多细节)
这个插件提供了一个coverityResults一步将从Coverity连接配置实例检索问题,项目,和视图。 通过添加这一步的管道将包括任何结果以同样的方式发现问题构建结果管道。
使用示例:
coverityResults connectInstance: ‘cov-connect‘, connectView: ‘JenkinsPipelineView‘, projectId: ‘my project‘
使用管道语法片段发生器得到帮助选择Coverity连接实例和验证项目和视图的价值观
高级选项可以中止管道,管道或管道标记为失败不稳定,如果任何问题被发现在Coverity连接视图(使用abortPipeline,failPipeline或unstable默认值,这些选项是错误的)。
abortPipeline优先于failPipeline和failPipeline优先于unstable。
视图可以配置在Coverity连接用户界面(使用相同的用户凭证,将连接在管道运行)。 看到Coverity平台用户和管理员指南信息配置视图。
视图必须配置为一个“快照”问题:视图类型。 这可以确保最近提交问题,通过保持默认视图的“Snaphost范围”last()。
视图应该包括列“CID”,“检查”,“文件”,“功能”为了妥善记录问题/管道运行(否则就计数可能如图所示)。
视图过滤器应该配置为管道的问题提交。 一个例子将过滤的“分类”“未分类”|“等待”|“错误”或“状态”的“新”|“筛选”
视图组通过设置必须设置为“无”与一组检索问题的观点是不支持。
注意,这个管道工作步骤大大不同于自由泳post-build步骤在两个主要方面:
检索的结果是每个项目,而不是每流。
在这种情况下,多个管道(或工作)提交到多个流在相同的项目中,不同的观点必须由适当的配置过滤流。
过滤配置完全Coverity连接,而不是在詹金斯配置
这允许过滤列上没有提供在post-build步骤以及更加动态日期过滤功能。
下面的脚本使用一个Coverity静态分析工具安装命名default,配置“用户名与密码”credentialId的凭据jenkins-cov-user,名叫Coverity连接配置实例cov-connect。 Coverity连接实例有一个项目命名my project(包含一个流命名为“我的流”)和一个名为“快照”问题:视图my view。
node {
stage(‘Preparation‘) {
// checkout the source code
git `<URL to Git Repository>`
}
stage(‘Run Coverity‘) {
// use a variable for the shared intermediate directory
iDir = ‘cov-idir‘
withCoverityEnv(coverityToolName: ‘default‘, connectInstance: ‘Coverity Connect Instance Name‘) {
// run cov-build capture command
sh "cov-build --dir ${iDir} <build-command>"
// run cov-analyze command
sh "cov-analyze --dir ${iDir}"
// run cov-commit-defects command
sh "cov-commit-defects --dir ${iDir} --host ${COVERITY_HOST} --port ${COVERITY_PORT} --stream my stream"
}
// cleanup intermediate directory after commit was made (optional space saving step)
dir("${iDir}") {
deleteDir()
}
}
stage(‘Coverity Results‘) {
coverityResults connectInstance: ‘cov-connect‘, connectView: ‘my view‘, projectId: ‘my project‘
}
}
在这个例子中Coverity执行保存在一个Run Coverity阶段,为了打破Coverity命令到单独的阶段需要一个共享的中间目录。 建议使用外部工作空间管理器插件如果这是必要的(中间目录通常是大型储备/ unstash步骤)。
原文地址：https://www.cnblogs.com/ming369/p/10618660.html