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
  

实施细节

项目结构设计

1. ai-code-review-tool/
2. ├── setup.py                    # 包定义和依赖管理
3. ├── ai_code_review/
4. │   ├── __init__.py
5. │   ├── cli.py                  # 命令行接口，封装审查逻辑
6. │   └── ...                     # 其他模块
7. ├── .gitlab-ci.yml              # CI模板 + 自动发布作业
8. └── 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 中配置：
  1. variables:
  2.   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作业定义：
  1. stages:   - review  variables:
  2.   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框架处理复杂代码审查任务。
  

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

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

很好很强大  我过来先占个楼 待编辑