（二十）让 GitHub 重新运行项目检查

示例私有仓库已经实际运行了推送与 PR 检查。Actions 列表中的绿色勾表示对应工作流通过；点进某次运行可继续查看 job 和具体步骤的输出。先确定运行对应哪条分支、哪次提交，再判断结果。

1. 把本地检查接到 Pull Request

第六章已经有 tools/check.py。在完整项目根目录中建立 .github/workflows/python-checks.yml，GitHub Actions 就能在推送与 PR 更新时建立环境，重新执行相同检查。下面的配套模板应用到第六章的 quality_project：

# 项目文件：templates/python-checks.yml
# 放到完整项目的 .github/workflows/python-checks.yml，执行已有检查入口。
name: Python checks
on: [push, pull_request]

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"
      - name: Install project and development tools
        run: |
          python -m pip install -e .
          python -m pip install -r requirements-dev.txt
      - name: Run checks
        run: python tools/check.py

YAML 用缩进表达层级，on 选择触发事件，jobs 保存任务，steps 按顺序执行。uses 调用已发布的 Action，run 执行命令；| 把接下来的多行作为一段脚本。checkout 取得代码，setup-python 准备 Python 3.12，随后安装并运行第六章同一组工具。Python Actions 教程、checkout、setup-python

2. 阅读一次远程检查失败

在 PR 的 Checks 或仓库 Actions 页面打开失败任务，先找第一个失败的 step，再读具体命令输出。若是 Ruff 报名称问题，回到对应文件；若 pytest 显示断言差异，用同一输入在本地重跑。修正、提交、推送后，新的检查再次运行。

Actions 的成功表示这次提交在配置的环境与检查中通过。合并前仍要阅读差异和任务目标；保护规则还可以要求指定检查通过后才允许合入 main。构建 wheel、上传附件与部署服务可以以后再接入，不把一次测试工作流同时变成所有发布动作。