GitLab 與 SonarQube 整合

Search for a command to run...

No comments yet. Be the first to comment.
書本連結 前言 會挑這本書看的人,應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求,也希望能滿足可維護性(maintainability)的隱性需求,以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難,因為專案通常不會按照計畫進行。可能變因有 deadline,最後的 API 與承諾的不同,又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一

我們的 AIOps agent 有個很具體的問題:它會捏造 trace ID。 當 on-call 工程師問「payment service 有沒有 error trace?」,agent 有時會信心滿滿地回答「是的,見 trace a1b2c3d4...」——但這串 ID 根本不存在 Tempo 裡。工程師點進去,404。壞的不只是使用者體驗,而是這讓整個 RCA 結論失去可信度。 另一個問題是

o11y-bench 深入剖析:讓 AI 真正面對 on-call 現場 從任務設計、合成環境、Agent 架構、評分機制到報告輸出,逐一解析這個開放 benchmark 的每個組件——以及 Gemini 3 Flash Preview 的完整實測結果 先說清楚這在解決什麼問題 目前多數 LLM benchmark 測的是「知識」:模型知不知道 PromQL 的語法,知不知道什麼是 p99

臥龍神算奇術完全兵書:從兵法原理到實戰,徹底搞懂奇術機制

稟告主公:此乃司馬懿進呈之兵書,詳解如何以 OpenTelemetry 陣法,令臥龍神算之一舉一動盡在掌握,知糧草消耗、察兵器效能、辨戰報異常,使主公運籌帷幄於大帳之中。 為何需要斥候情報? 司馬懿稟告主公: 臥龍神算(Claude Code)乃當世利器,然若無斥候回報,主公便如蒙眼行軍——兵器耗損幾何、糧草消費幾許、哪路斥候出了差錯,一概不知。臣以為,此乃兵家大忌。 無情報之弊,有四: 軍

An example for go project on GitLab and integration with SonarQube
請參閱GitLab CI 可以自動檢測程式碼品質!SonarQube 程式碼品質檢測怎麼做?
因為我們其實都是使用 SonarScanner 在掃描然後才把結果上傳至 SonarQube server, 所以需要一隻檔案名為sonar-project.properties 來給scanner 解讀該專案的配置.
專案基本設定
sonar.projectKey=xxx # 專案在SonarQuber中的唯一識別碼
sonar.projectName=yyyy # 專案名稱
sonar.qualitygate.wait=true # 等待品質閘道檢查完成
sonar.scm.provider=git # 使用 git 作為version control
原始碼分析範圍設定
sonar.sources=. # 分析的根目錄(當前目錄)
sonar.inclusions=**/*.go # 只分析 .go 檔案
# 排除以下檔案:
sonar.exclusions=**/*_test.go,\
**/vendor/**,\
**/mock_*.go,\
**/*.pb.go,\
**/contract/*.go,\
**/*.pb.ts,\
**/docs/**
測試相關設定
sonar.tests=. # 測試檔案的根目錄
sonar.test.inclusions=**/*_test.go # 包含所有 test.go 檔案
sonar.test.exclusions=**/vendor/**, # 排除 vendor 目錄中的測試
sonar.go.coverage.reportPaths=coverage.out # 程式碼覆蓋率報告的路徑
sonar.go.tests.reportPaths=test.out # 測試結果報告的路徑
sonar.coverage.exclusions= # 不計入覆蓋率統計的檔案:
**/*_mock.go,\
**/mock/**/*,\
cmd/**/*,\
main.go,\
**/test/**/*,\
**/tests/**/*,\
infrastructure/**/*,\
internal/config/**/*,\
internal/driver/**/*
但其實 SonarQube Scanner 本身不會直接執行go test指令, 畢竟他裡面也沒安裝 Go SDK, 所以需要依賴預先產生的測試報告檔案.因此接著就看 CI pipeline 中怎將報告傳遞給 SonarQube Scanner.
在 GitLab CI 中,我們需要設定適當的 pipeline 來執行測試並產生報告給 SonarQube Scanner 使用。以下是一個基本的 .gitlab-ci.yml 配置範例:
stages:
- test
- sonarqube
unit-test:
stage: test
script:
# 執行測試並產生測試報告
- go test -json ./... > test.out
# 產生覆蓋率報告
- go test -coverprofile=coverage.out ./...
artifacts:
paths:
- test.out
- coverage.out
expire_in: 1 day # 設定報告檔案的保存期限
sonarqube-check:
stage: sonarqube
image:
name: sonarsource/sonar-scanner-cli
entrypoint: [""]
dependencies:
- unit-test # 確保能取得測試階段產生的報告
script:
- sonar-scanner
only:
- merge_requests
- main
- develop
這個 pipeline 主要分為兩個階段:
使用 golang 映像檔執行測試
產生兩個重要的報告檔案:
test.out:測試結果報告
coverage.out:程式碼覆蓋率報告
使用 artifacts 保存這些報告檔案
使用 SonarQube Scanner 官方映像檔
讀取先前產生的測試報告
執行程式碼品質分析
只在特定分支(main、develop)和合併請求時執行
注意事項:
Pipeline 需要搭配前面提到的 sonar-project.properties 設定檔使用
確保 GitLab CI 環境變數中已設定必要的 SonarQube 相關變數(如 SONAR_TOKEN)
測試報告會暫時保存一天,供 SonarQube 分析使用
使用快取來優化 SonarQube Scanner 的執行效能
這樣的設定可以確保每次程式碼更新時,都能自動執行測試並進行程式碼品質分析,幫助團隊維持程式碼品質。
當我們專案成功在 Scanner 掃描成功後, 就能在 SonarQube 網站上看到結果了.

且 SonarQube 還有個貼心的小功能, 就是能將結果以 Badge 的形式呈現. 點每個專案的Project Information 就能看到 Badges 了, 裡面有各種指標的 Bage 能選.


選擇好按下 Copy 後就能來到 GitLab 專案中, 一樣找到 Setting 頁面也有 Badge 能設定.


設定完成如下, 這樣我們的 GitLab Project 就能即時呈現 SonarQube 的 badge 了.


當然要是掃描失敗, 是該發訊息到 Slack 通知該團隊做優化或修復的動作.