博客 / 詳情

返回

gitlab系統拓展AI代碼自動審查多項目可複用架構

gitlab系統拓展AI代碼自動審查多項目可複用架構

概述

我相信大家再趕進度的時候最討厭的就是代碼review，時間緊迫，幾個項目並行的時候，review也是一個很大的開銷，外面的開源方案再安全性上都很差，導致沒有辦法實際落地，這裏開始設計一套可複用的架構，最初的AI代碼審查系統基於單項目腳本實現（如參考博客：https://www.cnblogs.com/duwenlong/p/19452150），每個項目維護獨立的 review.py 和 .gitlab-ci.yml。這種方式存在代碼重複、維護困難等問題。為此，我設計了共享工具方案，從單項目遷移到多項目可複用架構。後續持續迭代。

背景

  • 目標：自動化代碼審查，支持中文反饋，擴展為統計、RAG等高級功能。
  • 技術棧：Ollama (deepseek-coder模型), GitLab CI/CD, Python, GitLab API。
  • 挑戰：解決私有倉庫的include權限問題，實現跨項目的CI配置共享。

步驟1: 基礎設置

安裝Ollama和GitLab Runner

  • 下載Ollama二進制文件：wget https://.../ollama 並放置於 /home/user/Downloads/bin/ollama。
  • 啓動Ollama服務：nohup /home/user/Downloads/bin/ollama serve &。
  • 註冊GitLab Runner：使用 gitlab-runner register 命令，選擇shell executor，設置標籤為 ai-review。
  • 配置systemd服務：創建 /etc/systemd/system/ollama.service 文件，確保Ollama隨系統啓動。

創建第一個項目 (示例項目2)

  • 克隆示例項目2項目：git clone https://gitlab.example.com/.../project2.git。
  • 開發核心腳本 review.py：集成GitLab API和Ollama，生成代碼審查反饋。
  • 配置 .gitlab-ci.yml：定義觸發條件（push和merge request），執行審查腳本。
  • 設置環境變量：添加 GITLAB_TOKEN 用於API訪問。

（前面的內容可參考博客：https://www.cnblogs.com/duwenlong/p/19452150）

步驟2: 擴展到多個項目

配置示例項目3

  • 克隆示例項目3項目。
  • 複製示例項目2的CI配置和審查腳本。
  • 優化CI管道：添加 GIT_DEPTH: 1 減少克隆深度，設置 timeout: 30m 避免長時間運行。

配置示例項目1

  • 類似示例項目3的配置過程。

步驟3: 創建共享工具 (ai-code-review-tool)

初始設計思路：Python包 + CI Include

  • 方法選擇：採用Python包封裝核心邏輯，通過GitLab CI的include機制共享CI模板，實現代碼複用。
  • 優勢：
    • 核心功能集中維護，避免各項目重複開發。
    • CI配置標準化，簡化項目接入。
    • 支持版本控制和自動更新。
  • 工具位置：https://gitlab.example.com/example-team/ai-code-review-tool

實施細節

項目結構設計

ai-code-review-tool/
├── setup.py                    # 包定義和依賴管理
├── ai_code_review/
│   ├── __init__.py
│   ├── cli.py                  # 命令行接口，封裝審查邏輯
│   └── ...                     # 其他模塊
├── .gitlab-ci.yml              # CI模板 + 自動發佈作業
└── ci-review.yml               # 共享CI配置模板

核心組件開發

  • setup.py：定義包元數據、依賴（python-gitlab, ollama等）和入口點。
  • cli.py：實現命令行工具 ai-review，支持項目ID、MR IID等參數，調用Ollama生成審查反饋。
  • ci-review.yml：定義標準CI作業模板，包括觸發規則、環境變量、腳本執行。

自動發佈機制

  • pypi-publish作業：在tag推送時自動構建和發佈包到GitLab Package Registry。
  • 版本管理：使用語義化版本，確保兼容性和更新通知。

權限挑戰與解決方案

遇到的問題

  • include權限限制：私有倉庫的remote include需要特殊權限配置，導致"Invalid configuration format"錯誤。
  • 訪問控制：即使啓用"Allow anyone to pull from package registry"，CI include仍受項目可見性限制。
  • 維護複雜性：依賴外部文件增加了配置的脆弱性。

解決方案：直接嵌入CI作業

  • 設計調整：放棄include機制，將共享CI作業直接複製到各項目的 .gitlab-ci.yml 中。
  • 優勢：
    • 消除權限依賴，確保各項目獨立運行。
    • 簡化配置，減少外部依賴。
    • 保持代碼複用（通過共享包），同時保證CI配置的自主性。
  • 遷移策略：逐步替換各項目的include為嵌入式配置，確保平滑過渡。

更新引用項目

  • 示例項目1：最初測試include方式，後因權限問題轉為嵌入。
  • 示例項目2：master和OTA4分支均採用嵌入配置。
  • 示例項目3：OTA2分支嵌入CI作業。

遷移過程

  1. 從單項目腳本遷移：提取公共邏輯到共享包。
  2. 測試include方案：驗證包安裝和CI觸發。
  3. 識別權限問題：分析失敗原因，調整為嵌入方案。
  4. 多項目部署：逐個更新項目的CI配置，確保一致性。

步驟4: 權限和發佈設置

設置項目權限

  • 將ai-code-review-tool項目設為私有。
  • 啓用"Allow anyone to pull from package registry"選項，允許通過API拉取包而無需額外認證。
  • 此配置確保團隊成員可安裝包，同時保持代碼私有。

獲取項目ID

  • 在GitLab項目頁面，查看URL或進入Settings > General獲取Project ID（例如：12345）。

更新PYPI_INDEX_URL

  • 在各項目的 .gitlab-ci.yml 中配置： 
    variables:
  PYPI_INDEX_URL: 'https://gitlab.example.com/api/v4/projects/12345/packages/pypi/simple'

測試發佈

  • 推送tag觸發pypi-publish作業。
  • 檢查CI管道日誌，確保包構建和上傳成功。
  • 驗證Package Registry中包的存在。
  • Runner配置：設置 run_untagged=true 和 request_concurrency=2，確保非tag作業正常運行。

步驟5: 驗證和測試

  • 在各項目推送代碼，觀察CI管道執行。
  • 確認包安裝成功，審查腳本正常運行並生成反饋。

步驟6: 最終部署和多項目配置

解決include權限問題

  • 由於私有倉庫的include機制受限，轉為直接嵌入CI作業。
  • 標準CI作業定義： 
    stages:
  - review

variables:
  PYPI_INDEX_URL: 'https://gitlab.example.com/api/v4/projects/12345/packages/pypi/simple'

ai_code_review:
  stage: review
  tags:
    - ai-review
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_PIPELINE_SOURCE == "push"
  variables:
    GIT_DEPTH: 1
  timeout: 30m
  before_script:
    - pip install ai-code-review-tool --index-url $PYPI_INDEX_URL
  script:
    - |
      if [ -n "$CI_MERGE_REQUEST_IID" ]; then
        ai-review --project-id $CI_PROJECT_ID --mr-iid $CI_MERGE_REQUEST_IID --gitlab-url $CI_SERVER_URL --token $GITLAB_TOKEN
      else
        ai-review --project-id $CI_PROJECT_ID --gitlab-url $CI_SERVER_URL --token $GITLAB_TOKEN
      fi

部署到目標項目

  • 示例項目2項目：
    • master分支：嵌入CI作業，提交併推送。
    • YBS3-OTA4分支：類似處理，確保分支特定配置。
  • 示例項目3項目：
    • OTA2分支：嵌入CI作業。
  • 示例項目1項目：
    • main分支：嵌入CI作業。

所有更改均通過Git提交和推送，確保版本控制和可追溯性。

總結

通過創建共享Python包並直接嵌入CI配置，實現了AI代碼審查系統的可擴展部署。權限配置確保了安全性和可用性，為團隊提供了高效的代碼質量保障工具。

注意事項

  • Token安全：始終使用CI變量存儲敏感信息，避免硬編碼。
  • 權限管理：確保所有團隊成員對相關項目具有適當訪問權限。
  • 測試驗證：每次配置更新後，進行全面測試以驗證CI管道功能。
  • 維護策略：定期更新共享工具包，同步各項目的CI配置。

擴展計劃

  • 統計系統：集成數據庫記錄審查結果，生成質量報告。
  • RAG集成：使用向量數據庫檢索相關代碼知識，提升審查準確性。
  • 任務編排：採用LangChain框架處理複雜代碼審查任務。

看看等我做完之後能不能抽離成開源項目。

操作系統
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.