在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

huggingface/transformers

菜单

CI/CD 和通知

相关源文件

本页面记录了 Transformers 库中使用的持续集成/持续部署 (CI/CD) 基础设施和通知系统。它涵盖了测试如何自动运行、结果如何报告以及通知如何发送给团队成员。

有关构建系统和依赖项管理的信息，请参阅构建系统。有关测试框架本身的信息，请参阅测试框架。

CI/CD 架构概述

Transformers 库结合使用 GitHub Actions 和 CircleCI 作为其 CI/CD 管道。该系统旨在：

  1. 在代码推送或创建拉取请求时自动运行测试
  2. 筛选测试以仅运行受代码更改影响的测试
  3. 将测试工作负载分配到多台机器
  4. 通过 Slack 向团队成员报告测试结果
  5. 随着时间推移跟踪测试失败以识别回归问题

来源：.github/workflows/self-scheduled.yml1-570 .circleci/config.yml1-139 utils/tests_fetcher.py1-50 utils/notification_service.py1-100

CI 工作流

Transformers 库根据不同目的使用几种不同的 CI 工作流：

  1. 拉取请求 CI：当创建或更新 PR 时，在 CircleCI 上运行
  2. 推送 CI：当代码推送到特定分支时，在自托管运行器上运行
  3. 每日 CI：在自托管运行器上定时运行以测试主分支
  4. 文档测试 CI：定时运行以测试文档示例

拉取请求 CI

当创建或更新拉取请求时，CircleCI 会被触发以运行测试。其过程为：

  1. config.yml 工作流被触发
  2. fetch_tests 任务根据更改的文件确定要运行的测试
  3. 生成包含所选测试的动态配置
  4. 测试在多台机器上并行运行
  5. 结果作为 GitHub 检查报告

来源：.circleci/config.yml1-139 .circleci/create_circleci_config.py1-429 utils/tests_fetcher.py1-565

自托管运行器

对于更密集的测试，尤其是需要 GPU 的测试，该库在 AWS 上使用自托管运行器。这些运行器用于：

  1. 推送 CI：当代码推送到特定分支（如 ci_* 或 ci-*）时
  2. 每日 CI：主分支的定时运行
  3. AMD GPU CI：针对 AMD GPU 的特定测试

自托管运行器按机器类型组织：

  • aws-g4dn-4xlarge-cache：单 GPU 机器
  • aws-g4dn-12xlarge-cache：多 GPU 机器
  • 用于在 AMD 硬件上测试的 AMD 专用运行器

来源：.github/workflows/self-scheduled.yml1-570 .github/workflows/self-push.yml1-500 .github/workflows/self-scheduled-amd-mi250-caller.yml1-60

测试选择系统

CI 系统的一个关键特性是它能够根据代码更改智能选择要运行的测试。这通过 tests_fetcher.py 脚本实现。

测试选择的工作原理

  1. 识别修改的文件：确定当前提交与基准提交之间哪些文件已更改
  2. 提取依赖项：分析导入以构建代码库的依赖关系图
  3. 确定受影响的模块：查找所有依赖于修改文件的模块
  4. 选择测试：选择覆盖受影响模块的测试
  5. 筛选核心模型：如果太多模型受到影响，则侧重于核心模型

来源：utils/tests_fetcher.py16-565

重要模型选择

当太多模型受到更改影响时，系统会优先测试“重要”模型，其中包括：

  1. 下载量最多的模型（BERT、CLIP、T5 等）
  2. 特定于管道的模型（以确保每个管道至少有一个模型被测试）

这在 tests_fetcher.py 文件中的 IMPORTANT_MODELS 列表中定义。

来源：utils/tests_fetcher.py76-104

通知系统

Transformers 库有一个精密的通知系统，可以将测试结果报告到 Slack 频道。这通过 notification_service.py 脚本实现。

Slack 报告

测试结果根据测试类型报告到不同的 Slack 频道：

  • #transformers-ci-daily-models：模型测试
  • #transformers-ci-daily-pipeline-torch：PyTorch 管道测试
  • #transformers-ci-daily-pipeline-tf：TensorFlow 管道测试
  • #transformers-ci-daily-examples：示例测试
  • #transformers-ci-daily-training：训练和 FSDP 测试
  • #transformers-ci-daily-quantization：量化测试
  • #transformers-ci-daily-docs：文档测试
  • #transformers-ci-daily-amd：AMD 专用测试

来源：utils/notification_service.py1-1000 .github/workflows/slack-report.yml1-94 .github/workflows/self-scheduled-caller.yml1-132

消息格式

Slack 消息包括：

  1. 测试结果摘要（失败和成功数量）
  2. 按模型和类别划分的失败细分
  3. 与之前运行的比较以识别新的失败
  4. 详细测试报告链接
  5. 关于失败责任人的信息

示例消息结构

Daily CI

There were 15 failures, out of 1250 tests.
The suite ran in 3h45m12s.

The following categories had failures:
Single |  Multi | Category
     3 |      2 | PyTorch
     1 |      0 | TensorFlow
     
These following model modules had failures:
Single PT |  Multi PT | Single TF |  Multi TF |     Other | Category
        2 |         1 |         0 |         0 |         0 | bert
        1 |         0 |         1 |         0 |         0 | gpt2
        0 |         1 |         0 |         0 |         0 | t5

There are 5 new failed tests
(compared to previous run: 1234567)

来源：utils/notification_service.py124-278

故障分析与追踪

CI 系统包含用于随时间追踪和分析测试失败的工具：

  1. 与之前运行进行比较：通过与之前的 CI 运行进行比较来识别新的失败
  2. 查找问题提交：check_bad_commit.py 脚本使用 git bisect 查找哪个提交引入了失败
  3. 分配责任：失败被映射到负责提交的作者和审阅者

来源：utils/check_bad_commit.py1-207 utils/process_bad_commit_report.py1-150 .github/workflows/check_failed_tests.yml1-170

Docker 镜像

CI 系统使用多种 Docker 镜像进行不同类型的测试：

图片目的
huggingface/transformers-all-latest-gpu所有框架的通用测试
huggingface/transformers-pytorch-gpuPyTorch 专用测试
huggingface/transformers-tensorflow-gpuTensorFlow 专用测试
huggingface/transformers-pytorch-deepspeed-latest-gpuDeepSpeed 测试
huggingface/transformers-quantization-latest-gpu量化测试
huggingface/transformers-pytorch-amd-gpuAMD GPU 测试
huggingface/transformers-quality代码质量检查
huggingface/transformers-consistency仓库一致性检查

来源：.github/workflows/self-scheduled.yml60-460 .github/workflows/self-push.yml38-365 .circleci/config.yml42-143

定时 CI 运行

该库有几个定时 CI 运行：

  1. 每日 CI：每天 UTC 时间凌晨 2:17 运行，测试主分支
  2. 文档测试 CI：每天 UTC 时间凌晨 2:17 运行，测试文档示例
  3. AMD CI：定时运行，用于在 AMD 硬件上进行测试

这些定时运行有助于识别可能未被特定于 PR 的测试捕获的回归问题。

来源：.github/workflows/self-scheduled-caller.yml1-132 .github/workflows/doctests.yml1-90 .github/workflows/self-scheduled-amd-mi250-caller.yml1-60

CI 环境变量

CI 系统使用多个环境变量来控制其行为：

可变目的
TRANSFORMERS_IS_CI指示代码在 CI 环境中运行
HF_HOMEHugging Face 模型缓存目录的路径
OMP_NUM_THREADS控制 OpenMP 线程数
MKL_NUM_THREADS控制 MKL 线程数
RUN_SLOW在 CI 中启用慢速测试
PYTEST_TIMEOUT设置测试超时时间
TF_FORCE_GPU_ALLOW_GROWTH控制 TensorFlow GPU 内存分配
CUDA_VISIBLE_DEVICES控制对测试可见的 GPU

来源：.github/workflows/self-scheduled.yml36-48 .github/workflows/self-push.yml20-27 .circleci/config.yml145-147

发布流程

CI/CD 系统还支持 Transformers 库的发布过程。这记录在 setup.py 文件中，其中包含详细说明：

  1. 创建发布分支
  2. 运行发布前检查
  3. 构建和测试软件包
  4. 上传到 PyPI
  5. 发布后任务

发布过程通过 Makefile 目标实现半自动化。

make pre-release      # Prepare for a full release
make pre-patch        # Prepare for a patch release
make build-release    # Build the release packages
make post-release     # Post-release version bump

来源：setup.py15-67 Makefile110-127

CI 问题排查

CI 系统中的常见问题包括：

  1. 不稳定的测试：间歇性失败的测试会用 @is_flaky 标记，并可能自动重新运行
  2. 运行器可用性：自托管运行器可能离线，这通过 check_self_hosted_runner.py 进行检查
  3. 测试选择问题：如果选择了错误的测试，请检查 tests_fetcher.py 中的依赖项分析
  4. 通知失败：如果 Slack 通知不起作用，请检查令牌配置

CI 系统包含针对不稳定测试的重试机制，其模式在 FLAKY_TEST_FAILURE_PATTERNS 中定义。

来源：.circleci/create_circleci_config.py38-55 utils/check_self_hosted_runner.py1-53