（三十三）用持续集成重复交付检查

第七章已经介绍过 GitHub 和自动检查。这里把本地的 tools/check.py 接入 Actions，让每个提交分别检查两个项目。将整个“综合项目与交付”目录作为仓库根目录时，下面的相对路径直接对应两个项目。

# 项目文件：.github/workflows/check.yml
# 两个项目分别重建环境；本地 tools/check.py 与这里执行同一检查入口。
name: Check reading projects
on: [push, pull_request]
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        project: [catalog_project, model_project]
    defaults:
      run:
        working-directory: ${{ matrix.project }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install fixed uv
        run: python -m pip install uv==0.9.24
      - name: Rebuild environment
        run: uv sync --locked
      - name: Test and run complete flow
        run: uv run python tools/check.py
      - name: Build wheel
        run: uv build --wheel
      - name: Build container image
        run: docker build -t reading-${{ matrix.project }} .

矩阵 project 分别取两个项目目录；每个任务安装 Python 3.12 与固定的 uv，按锁定结果安装，再执行相同检查入口。业务检查成功后，构建 wheel 和镜像。某一步失败，先看该步日志；不把失败检查跳过再继续发布。

同一提交分别进入两个项目的任务，按环境重建、业务与 HTTP 检查、安装包和镜像构建逐步推进

这份工作流只执行检查与构建。实际发布可以在检查成功后增加明确的镜像标签、目标服务器和启动步骤。提交、依赖锁和模型版本会分别改变，发布记录需要将它们关联起来。Actions 的 Python 环境设置可对照 GitHub 官方教程。