基于docker的AI-Codereview-Gitlab部署实战

AI-Codereview-Gitlab是一个基于大模型的自动化代码审查工具，帮助开发团队在代码合并或提交时，快速进行智能化的审查(Code Review)，提升代码质量和开发效率。

主要功能

• 多模型支持
  • 兼容 DeepSeek、ZhipuAI、OpenAI、通义千问 和 Ollama，想用哪个就用哪个。
• 消息即时推送
  • 审查结果一键直达 钉钉、企业微信 或 飞书，代码问题无处可藏！
• 自动化日报生成
  • 基于 GitLab & GitHub Commit 记录，自动整理每日开发进展，谁在摸鱼、谁在卷，一目了然 。
• 可视化 Dashboard
  • 集中展示所有 Code Review 记录，项目统计、开发者统计，数据说话，甩锅无门！
• Review Style 任你选
  • 专业型 ：严谨细致，正式专业。
  • 讽刺型 ：毒舌吐槽，专治不服（"这代码是用脚写的吗？"）
  • 绅士型 ：温柔建议，如沐春风（"或许这里可以再优化一下呢~"）
  • 幽默型 ：搞笑点评，快乐改码（"这段 if-else 比我的相亲经历还曲折！"）

工作原理

当用户在 GitLab 上提交代码（如 Merge Request 或 Push 操作）时，GitLab 将自动触发 webhook事件，调用本系统的接口。系统随后通过第三方大模型对代码进行审查，并将审查结果直接反馈到对应的 Merge Request 或 Commit 的Note 中，便于团队查看和处理。

以上均为官方描述，下面进行实战部署操作。

部署实战

官方给了两种部署方案，分别是Docker部署和本地Python环境部署，我们采用的是第一种，并且根据实战操作对部分内容进行了修改。

1. 前期环境准备

操作系统：centos7

Docker版本：24.0.0

Docker-Compose版本：v2.28.0

git版本：1.8.3.1

• Docker国内镜像源设置：

  vim /etc/docker/daemon.json
  

  将daemon.json改为如下内容：

  {
       "registry-mirrors": ["https://registry.docker-cn.com","https://pee6w651.mirror.aliyuncs.com"],
       "live-restore": true
  }
  

  保存成功后，运行如下命令进行重新加载：

  systemctl daemon-reload
  systemctl restart docker
  

2.获取源码

实战命令(由于访问GitHub经常超时或者时间较长)：

cd /opt
git clone https://gitcode.com/gh_mirrors/ai/AI-Codereview-Gitlab.git
cd AI-Codereview-Gitlab

官方命令：

cd /opt
git clone https://github.com/sunmh207/AI-Codereview-Gitlab.git
cd AI-Codereview-Gitlab

3. 配置文件

获取源码后，在AI-Codereview-Gitlab目录下，创建配置文件，执行如下命令：

cp conf/.env.dist conf/.env
vim conf/.env

编辑 conf/.env 文件，配置以下关键参数：

• 大模型供应商配置参数，此处采用本地ollama部署的Deepseek:32B的大模型，因此修改如下参数部分：

  #大模型供应商配置,支持 deepseek, openai,zhipuai,qwen 和 ollama
  LLM_PROVIDER=ollama
  ...
  #OllaMA settings; 注意: 如果使用 Docker 部署，127.0.0.1 指向的是容器内部的地址。请将其替换为实际的 Ollama服务器IP地址。
  OLLAMA_API_BASE_URL=http://127.0.0.1:11434
  OLLAMA_API_MODEL=deepseek-r1:32b
  ...
  

• Gitlab配置，由于本地GitLab端口不是默认80，因此修改如下参数部分：

  #Gitlab配置
  GITLAB_URL=http://192.168.1.111:9080/ #部分老版本Gitlab webhook不传递URL，需要开启此配置，示例：https://gitlab.example.com
  #GITLAB_ACCESS_TOKEN={YOUR_GITLAB_ACCESS_TOKEN} #系统会优先使用此GITLAB_ACCESS_TOKEN，如果未配置，则使用Webhook 传递的Secret Token
  

  同时还需要修改api.py文件内容，修改内容如下：

  将
  def handle_github_webhook(event_type, data):
      # 获取GitHub配置
      github_token = os.getenv('GITHUB_ACCESS_TOKEN') or request.headers.get('X-GitHub-Token')
  ...
  改为：
  def handle_github_webhook(event_type, data):
      # 获取GitHub配置
      github_token = os.getenv('GITHUB_ACCESS_TOKEN')
  ...
  

• 推送配置，由于本次没有设置企微或钉钉推送，因此未进行相关配置，有需求根据env中的提示进行配置。

4. 镜像修改

官方配置的镜像源部分位于境外，导致部署过程中下载较慢或者网络异常，因此需要修改docker-compose.yml和Dockerfile中的部分参数，具体如下：

• 修改docker-compose.yml中的image参数：

• 修改Dockerfile中Python 基础镜像和依赖源参数：

  # 使用官方的 Python 基础镜像改为swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/python:3.10-slim国内
  FROM swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/python:3.10-slim AS base
  ...
  # 安装依赖加上国内源
  RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.mirrors.ustc.edu.cn/simple/
  

  修改完成后进行保存。

5. 启动服务

docker-compose up -d

6. 验证部署

• 主服务验证：
  • 访问 http://your-server-ip:5001
  • 显示 "The code review server is running." 说明服务启动成功。
• Dashboard 验证：
  • 访问 http://your-server-ip:5002
  • 看到一个审查日志页面，说明 Dashboard 启动成功。

7. 配置 GitLab Webhook

创建Access Token

方法一：在 GitLab 个人设置中，创建一个 Personal Access Token。

方法二：在 GitLab 项目设置中，创建Project Access Token。

注：创建的Access Token需要复制后单独保存，否则无法再次获取。

配置 Webhook

在 GitLab 项目设置中，配置 Webhook：

• URL：http://your-server-ip:5001/review/webhook
• Trigger Events：勾选 Push Events 和 Merge Request Events (不要勾选其它Event)
• Secret Token：上面配置的 Access Token(可选)

备注

1. Token使用优先级
   
   - 系统优先使用 .env 文件中的 GITLAB_ACCESS_TOKEN。
   
   - 如果 .env 文件中没有配置 GITLAB_ACCESS_TOKEN，则使用 Webhook 传递的Secret Token。
2. 网络访问要求
   
   - 请确保 GitLab 能够访问本系统。
   
   - 若内网环境受限，建议将系统部署在外网服务器上。

8. 配置消息推送

配置钉钉推送

• 在钉钉群中添加一个自定义机器人，获取 Webhook URL。

• 更新 .env 中的配置：

  #钉钉配置
  DINGTALK_ENABLED=1  #0不发送钉钉消息，1发送钉钉消息
  DINGTALK_WEBHOOK_URL=https://oapi.dingtalk.com/robot/send?access_token=xxx #替换为你的Webhook URL
  

企业微信和飞书推送配置类似。

最终效果