[Bug] e2e.yml 定时任务在 Fork 仓库中触发并因缺少 Secret 报错

[zth0828]

问题概述 (Summary)

.github/workflows/e2e.yml 中定义了每天夜间定时运行的调度任务：

schedule:
  - cron: '17 0 * * *'

当开发者 Fork 本仓库到个人账户后，GitHub Actions 会默认继承并自动运行该定时任务。由于外部社区 Fork 仓库不具备上游专有的仓库 Secret DEEPSEEK_API_KEY_EXTERNAL，导致该工作流在 Preflight (require DEEPSEEK_API_KEY) 步骤中硬性断言失败退出：

##[error]DEEPSEEK_API_KEY is empty. The e2e suite would self-skip and
##[error]report a false green. Configure the repo secret DEEPSEEK_API_KEY_EXTERNAL.
##[error]Process completed with exit code 1.

这会导致所有 Fork 了本项目的开发者每天都会收到失败通知邮件，并白白消耗 Fork 仓库的 GitHub Actions 免费额度。

复现步骤 (Reproduction)

1. Fork deepseek-ai/deepseek-harness 到个人 GitHub 账户。
2. 保持 Fork 仓库的 GitHub Actions 开启。
3. 每天北京时间 08:17（00:17 UTC）定时任务触发，或向 Fork 仓库的 master 分支同步提交代码。
4. 查看 Actions 运行记录，E2E (real DeepSeek API) 在 Preflight 阶段报错。

预期行为与建议修复 (Expected Behavior & Fix Suggestion)

依赖上游专有 Secret 的定时测试工作流，应当在 job 或 schedule 级别增加仓库守卫（Repository Guard），确保仅在官方主仓库运行，避免在 Fork 仓库中无效执行。

例如可以在 .github/workflows/e2e.yml 中添加仓库过滤判断：

jobs:
  e2e:
    if: >-
      github.repository == 'deepseek-ai/deepseek-harness' &&
      (github.event_name != 'pull_request' || !(github.event.pull_request.head.repo.fork || github.event.pull_request.user.login == 'dependabot[bot]'))

或者限制 schedule 仅在 deepseek-ai/deepseek-harness 触发。

[PerryLink]

你说得对，这个缺口是真的，我把 job 级 if: 逐字核了一遍 —— 现有条件对 schedule 事件完全不起作用。补一条关于仓库名的提醒，它会让你的补丁失效。

1. 现有守卫拦不住 schedule —— 机制确认

.github/workflows/e2e.yml：

jobs:
  e2e:
    if: >-
      github.event_name != 'pull_request'
      || !(github.event.pull_request.head.repo.fork || github.event.pull_request.user.login == 'dependabot[bot]')

（:62-64；上面 :60-61 的注释写着 "Run on every trusted event. Skip untrusted PRs (forks + Dependabot) where the secret is withheld"。）

问题在于第一个析取项。 定时触发时 github.event_name 是 'schedule'，不等于 'pull_request' ⇒ 第一项为真 ⇒ 整个 || 为真 ⇒ job 照跑。

⇒ 所以在一个 fork 里，夜间的 cron: '17 0 * * *'（:38-39，注释说明是 08:17 Asia/Shanghai）会照常运行，然后在 Preflight 硬失败：

##error::DEEPSEEK_API_KEY is empty. The e2e suite would self-skip and
##error::report a false green. Configure the repo secret DEEPSEEK_API_KEY_EXTERNAL.

（:88-100，Preflight 步骤的注释还专门解释了为什么要硬失败："the e2e suites self-skip when the key is absent, so a missing/misconfigured secret would otherwise pass as 'all skipped'"。）

设计意图是对的（防假绿），但守卫的范围漏了 schedule。 你的判断准确。

2. 这个 workflow 是唯一带 schedule 的

git grep -ln "schedule:" .github/workflows → 只有 e2e.yml。所以补这一个文件就够，不存在"还有别的 workflow 也这样"。

3. ⚠️ 关键提醒：别照抄仓库名，现有守卫用的是另一个名字

我在仓库里找到的既有 github.repository == 守卫全部是：

• .github/workflows/release.yml:34 与 :94 → github.repository == 'deepseek-harness/deepseek-harness'
• .github/workflows/release-vendor.yml:35 → 同上

而你这个 checkout 的 remote 是 deepseek-ai/deepseek-harness。 两个名字在本仓库的文档与笔记里都存在。

⇒ 这意味着两件事，都请先确认再写补丁：

1. 一个写错字面量的守卫会「静默失效」 —— 它不会报错，只会让条件恒为假。所以你提议的 github.repository == 'deepseek-ai/deepseek-harness' 如果与运行时实际值不符，这个补丁看起来加上了守卫、实际上什么都没拦。
2. 怎么确认：在仓库的 Actions 里跑一次 workflow_dispatch，在日志里打印一次 ${{ github.repository }}；那个值就是唯一正确的字面量。

⚠️ 顺带说一句：如果现有那两处 release*.yml 的守卫字面量与运行时值不符，它们自身也是失效的（那两条是 vars.DSH_CI_FAILOVER_LINUX == 'selfhosted' 的自托管路径选择）。我没有核实仓库是否改过名，所以不断言 —— 但你在报告里可以提一句"建议顺带核对既有守卫的字面量"，这是个有价值的附注。

更稳的写法（不依赖字面量）：把"是否官方仓库"换成"这个 secret 是否可得"。例如让 Preflight 在 非 PR 事件且 secret 缺失时，判断 github.repository 是否等于 github.event.repository.full_name 之类，或者干脆给 schedule 事件单独加一个条件。不过就最小改动而言，加一个正确的仓库字面量守卫即可。

4. 你的 if: 写法有一处冗余

你建议的：

if: >-
  github.repository == 'deepseek-ai/deepseek-harness' &&
  (github.event_name != 'pull_request' || !(...fork || dependabot...))

后半段与现有的 if: 完全相同 ⇒ 实际上你只需要在最前面加 github.repository == '<正确的名字>' &&。建议把补丁写成"在既有 if: 前追加一个合取项"，这样 diff 最小、也最容易审。

5. 一个对你的诉求有利的细节

e2e.yml:22-24 的注释写着：

A job skipped by a job-level if: reports as a SUCCESSFUL check, so this workflow is safe to use as a required status check if desired.

⇒ 加仓库守卫不会让 fork 里出现"被跳过但是红叉"，而是正常的 success。这一点建议写进报告 —— 它预先回答了"守卫会不会带来新问题"。

6. 影响面（你说的对，可以保留）

• fork 每天收到失败通知邮件
• 白耗 fork 的 Actions 免费额度
• 而且它是失败退出（Process completed with exit code 1），不是静默跳过 —— 所以对 fork 主来说是一次次噪音

7. 版本

你没写版本。我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2），e2e.yml 的 schedule（:37-39）与 job 级 if:（:62-64）都在 ⇒ 缺口对最新线成立。

[zth0828]

非常感谢您如此详尽、专业的技术核对与提醒！

特别是关于仓库名字面量历史（deepseek-harness vs deepseek-ai）以及 schedule 守卫逻辑的分析，非常清晰透彻。

我个人目前仅作为使用者反馈该现象，暂时不打算为此提交 PR。如果您或社区其他开发者有兴趣，非常欢迎直接基于您的分析给官方提交 PR 修复。再次感谢您的专业解答！