CI Draft: Integrate VPTO Test CI

[and0d0]

草稿: 融合vpto的测试ci

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[reedhecre]

Codex Review

该评论由 review 机器人自动更新。

• PR: CI Draft: Integrate VPTO Test CI #702 CI Draft: Integrate VPTO Test CI
• Author: and0d0
• Base/Head: main / ci-vpto-merge
• Head SHA: 47bf3f274bc2
• Trigger: PR 有新提交
• Generated At: 2026-05-27T03:17:07Z
• Previous Head SHA: f53b840e2941
• Status: completed

Summary

检查到 3 个 CI 逻辑问题：分支检测脚本会直接失败、VPTO LLVM 与主线 LLVM 共享缓存键、手动触发永远不会运行新增的 VPTO 自托管作业。

Findings

1. P1 未定义的 `HEAD_REF` 会让 `build-and-test` 在 checkout 前直接失败 .github/workflows/ci.yml:111

新增的 Detect PR source fork 步骤在 set -u 下读取 ${HEAD_REF}，但 GitHub Actions 文档里提供的是 GITHUB_HEAD_REF，而且它也只会在 PR 事件中出现：https://docs.github.com/en/actions/reference/workflows-and-actions/variables 。当前这个变量名在所有事件里都是未定义的，因此这里会先报 unbound variable，后面的两个 checkout 步骤都不会执行。结果是整个 build-and-test 作业被回归打坏；remote-npu-validation 还依赖这个作业，所以 schedule / workflow_dispatch 也会被一并阻断。

2. P1 VPTO LLVM 分支和主线 LLVM 复用了同一个缓存键 .github/workflows/ci.yml:172

这次改动虽然在 Resolve LLVM source SHA 里区分了 VPTO LLVM 的源码提交，但缓存恢复/保存仍然只用 env.LLVM_COMMIT 这个主线 LLVM SHA 做 key。也就是说，IS_VPTO_FORK=true 时，工作流会把源码切到 vpto-dev/llvm-project:feature-vpto，却可能直接复用之前为主线 LLVM 生成的 llvm/build-assert；反过来，如果第一次写入缓存的是 VPTO 构建，后续普通 CI 也会拿到 VPTO 的二进制。这样 CI 实际验证的 LLVM/MLIR 工具链与源码分支不一致，既可能制造假红，也可能把真实集成问题放过去。

3. P2 `workflow_dispatch` 永远不会运行新增的 `vpto-sim-validation` 作业 .github/workflows/ci.yml:329

这个 job 的 if 明确把 workflow_dispatch 列为允许事件，但后半段又要求 startsWith(github.event.pull_request.head.ref, 'feature-vpto-')。手动触发并没有 pull_request payload，所以这部分条件在 workflow_dispatch 下不可能成立。GitHub 文档也说明 head ref 只在 PR 类事件里提供：https://docs.github.com/en/actions/reference/workflows-and-actions/variables 。结果就是手动触发时，这个新的 VPTO 自托管验证作业会被一直跳过，无法用于人工回归或补跑。