vllm-ascend 使用 GitHub Actions 运行CI保证代码质量。

测试流程被分为三个阶段：

Lint：使用 pre-commit 进行静态代码检查，配置可见 .github/workflows/_pre_commit.yml
单元测试：运行 tests/ut 下用例，配置可见 .github/workflows/_unit_test.yaml
端到端测试

我们如果针对模型增加 CI 维护，需要的是增加端到端集成测试。

CI 流程分层

CI 流程可分为两类， Per PR CI 与 Nightly CI。

Per PR CI

有代码提交时运行，又可以分为 Light 和 Full 两类。

E2E-Light

推送即启动。

配置可见 .github/workflows/pr_test_light.yaml，包含 UT 单元测试和一些轻量的端到端测试。

E2E-Full

committer 人工打标，有了 ready-for-test 标签才启动。

配置可见 .github/workflows/pr_test_full.yaml，是 E2E-Light 加上一些重型端到端测试用例。

Nightly CI

夜间构建版本（Nightly Build）是一种软件开发的自动化实践，指开发团队在每天深夜利用自动化工具将当天更新的所有代码进行编译、测试并打包生成的最新实验性版本；它的目的是通过每日高频集成来尽早发现代码冲突和潜在漏洞，虽然包含最前沿的功能，但由于未经深度测试，其稳定性通常较低。

涉及到夜间构建测试的配置文件很多，落实到模型方面，主要有两个：

A2机器：.github/workflows/nightly_test_a2.yaml
A2机器：.github/workflows/nightly_test_a3.yaml

如何增加模型看护测试用例？

Per CI

Per PR CI 主要关注变更对现有功能的影响。若需增加模型测试（通常是轻量级或核心路径测试）：

添加测试脚本：在 tests/e2e/ 相关目录下编写 pytest 测试脚本。
注册到工作流：修改 .github/workflows/_e2e_test.yaml。
- 找到 Run e2e test (针对 Full) 或 Run vllm-project/vllm-ascend test (针对 Light) 的步骤。
- 添加 pytest 命令调用你的测试脚本。

Nightly

注册用例

Nightly CI 用于大规模、长时间或覆盖更多模型的测试。

添加测试脚本：通常放置在 tests/e2e/nightly/ 目录下。
注册到工作流：
- 根据目标硬件（A2 或 A3），编辑 .github/workflows/nightly_test_a2.yaml 或 .github/workflows/nightly_test_a3.yaml。
- 在 matrix.test_config 列表中新增一项配置。
- 配置示例：
```
- name: my-new-model-test
  os: linux-aarch64-a3-4  # 指定运行节点类型
  tests: tests/e2e/nightly/single_node/models/test_my_model.py
```

mock Nightly 测试 (以 PR #5371 为例)

Mock Nightly 测试指的是在 PR 阶段，通过修改配置临时触发 Nightly 流水线，以验证新增的 Nightly 用例或相关变更。这通常用于调试或在合入前确保 Nightly 用例能正常运行。

我们以 #5371 这个 PR 为例说明如何 Mock。这个 PR 包含两个 commit：

e226fd6d9d802f3210586cfcc0a33a50ed993565，mock nighlty ci测试环境；
f5c36ad0e62ba3724562a7f562efb85aaf0da962，恢复 mock。

为了了解如何mock测试环境，我们看 e226fd6d9d802f3210586cfcc0a33a50ed993565 这个 commmit。

修改触发条件：在 .github/workflows/nightly_test_a3.yaml 中，临时注释掉 types: [ labeled ] 并添加 push 事件，使得每次提交都能触发测试。

on:
  pull_request: 
    branches:
      - 'main'
    # types: [ labeled ]  <-- 注释掉限制
  push:
    branches:
      - 'main'

精简测试矩阵：在 matrix 中注释掉其他无关的测试用例，仅保留当前需要验证的 multi-node-dpsk3.2-2node。

matrix:
  test_config:
    # - name: multi-node-deepseek-pd ... (注释掉其他用例)
    - name: multi-node-dpsk3.2-2node
      config_file_path: DeepSeek-V3_2-W8A8-A3-dual-nodes.yaml
      size: 2

强制代码同步：由于多机测试环境使用预构建镜像，为了运行 PR 中的最新代码（包含新添加的配置文件），在 tests/e2e/nightly/multi_node/scripts/run.sh 中显式拉取了该 PR 的代码：
```
upgrade_vllm_ascend_scr() {
    cd "$WORKSPACE/vllm-ascend"
    # 显式拉取 PR 5371 的代码
    git fetch origin pull/5371/head:pr-5371
    git checkout pr-5371
}
```
临时使用本地 Kubeconfig (针对多机/特定环境)：在 .github/workflows/_e2e_nightly_multi_node.yaml 中，临时修改了 kubeconfig 的获取方式，直接使用 Runner 本地的配置，绕过 Secrets 限制以便调试。
```
# echo "${{ secrets.KUBECONFIG_B64 }}" | base64 -d > $KUBECONFIG
cp /root/.cache/.kube/kubeconfig.yaml $KUBECONFIG
```

注意：这些修改仅用于调试验证，在 PR 合入前请务必 revert 掉针对 on、matrix 的临时修改以及硬编码的 git checkout 逻辑。

关于测试环境模板 (lws.yaml.jinja2)

在多机测试中，tests/e2e/nightly/multi_node/scripts/lws.yaml.jinja2 定义了 Kubernetes 集群的部署模板。通常情况下，开发者无需修改此文件。

只有在以下特殊调度场景下才需要对其进行微调：

故障机器规避：当集群中某些节点不可用或出现硬件故障时，通过修改该模板中的 affinity 或 nodeSelector 来手动排除这些机器（如 PR #5371 中增加的 affinity 配置）。
资源特殊需求：模型需要极大的共享内存或特殊的挂载卷。

starmountain1997

探索

vllm-ascend 模型看护案例开发指南