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作业。

迁移过程

从单项目脚本迁移：提取公共逻辑到共享包。
测试include方案：验证包安装和CI触发。
识别权限问题：分析失败原因，调整为嵌入方案。
多项目部署：逐个更新项目的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作业定义：

yaml 复制代码

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框架处理复杂代码审查任务。

看看等我做完之后能不能抽离成开源项目。