AI DevOps学习：用GitHub Actions跑通第一个AI模型CI流水线

AI DevOps学习的第一个落地点，不是搭一套大平台，而是让模型代码每次提交都能自动跑测试、构建镜像并留下可查的结果。
本文用GitHub Actions加Docker，在一个普通Python模型仓库里搭一条最小CI流水线，适合刚接触AI工程化、想先跑通一次完整流程的读者。

先明确这条流水线要解决什么

模型代码和普通后端代码一样，最怕“本地能跑、合并后坏掉”。
最小CI流水线只做三件事：安装依赖、运行单元测试、构建Docker镜像。
做完这三步，你就有了一个可重复的检查点，后续再往里面加模型评测、镜像推送和部署步骤。

需要准备的条件：

• 一个GitHub仓库，里面已有可运行的Python模型代码和requirements.txt
• 本地能正常执行pytest，测试文件放在tests/目录
• 仓库根目录有可用的Dockerfile，能构建出镜像
• 不需要服务器，GitHub Actions提供托管运行器

如果本地测试还没跑通，先修本地，不要直接上CI，否则排查成本会翻倍。

编写workflow文件

在仓库根目录创建.github/workflows/ci.yml，内容如下：

name: model-ci

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install pytest

      - name: Run tests
        run: pytest -q

      - name: Build Docker image
        run: docker build -t model-ci:test .

关键点说明：on只监听main分支的推送和合并请求，避免每次分支操作都触发；pytest -q在测试失败时会让整个job失败，这是CI的核心信号；
镜像只构建不推送，先验证Dockerfile可用。

提交这个文件后，打开仓库的Actions页面，应该能看到model-ci工作流开始运行。

容易踩的坑

依赖安装慢或超时：requirements.txt里如果包含大体积包，首次运行可能较久。
可以先确认本地pip install耗时，再决定是否拆分依赖文件或加缓存。

测试在CI失败但本地通过：常见原因是测试依赖了本地路径、环境变量或未提交的文件。
用git status确认所有测试需要的文件都已提交，路径使用相对路径。

Docker构建找不到文件：检查.dockerignore是否把模型文件或配置排除了，以及Dockerfile里的COPY路径是否和仓库结构一致。

权限或密钥问题：本文示例不涉及推送镜像和部署，所以不需要配置Secrets。
如果后续要推送镜像，再单独添加仓库Secrets，不要把密钥写进workflow文件。

怎么确认流水线真的有效

跑通一次绿色通过不算验证完成，建议做两次反向检查：

1. 故意改坏一个测试断言，推送后确认Actions里Run tests步骤变红，说明测试确实在拦截问题。
2. 把Dockerfile里某个COPY路径改错，确认Build Docker image步骤失败，说明构建检查有效。

两次检查都符合预期后，再恢复代码。
此时你得到的是一个可重复的CI基线，后面加模型评测、镜像推送或部署步骤，都可以在这条流水线上继续叠加。
AI DevOps学习到这一步，重点不是工具多，而是每次变更都有可验证的结果。

如果后续想继续深入，可以在这条流水线后面增加一个独立job做模型推理冒烟测试，或者把镜像推送到镜像仓库，再衔接部署流程。