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步驟)。