使用教程 · 2026

2026 GitHub 仓库 Push 邮件停发后，Actions 通知怎么验收？

这篇迁移教程适合需要替代仓库 Push 邮件的开发者、维护者和 QA。结论是：用 push 事件触发自有发送流程，但必须分别验证触发、发送端结果和测试收件箱实收；正文按准备、配置、测试与验收时间线给出配置示例和可勾选清单。

更新于 2026 年 10 月 27 日9 分钟阅读

GitHub 自带的仓库 Push 事件邮件通知已于 2026 年 10 月 15 日停发；如果仍需通知，应由 GitHub Actions 的 push 事件触发自有邮件发送流程，并用受控测试地址验收实收。适用前提是我们维护该仓库，或已获准配置它；工作流显示成功，不等于邮件已经进入收件箱。(GitHub Changelog 的停发说明)

独立开发者：需要替换原先用来查看代码变更的 Push 邮件。
仓库维护者：负责确认触发分支、收件人和发送凭据。
QA 或发布负责人：需要分清工作流运行、发送端接受和收件箱实收分别证明什么。

最后核实于 2026 年 10 月 27 日，政策核对自 GitHub Changelog，触发与凭据边界核对自 GitHub Actions 官方文档。

先划清停发范围，再确定迁移目标

停掉的是 GitHub 自带的仓库 Push 事件邮件通知，不是所有 GitHub 邮件，也不是 push 事件触发 Actions 的能力。官方说明，若要继续发送此类通知，可以用由 push 触发的工作流，通过自有 SMTP 服务器或邮件服务发信。它是我们维护的发送路径，并非原生通知恢复。(GitHub 官方停发公告)

先写清楚要通知的对象和事件范围：哪些自有或获授权仓库、哪些分支、哪些提交需要发信。若默认对每次推送都通知全部团队成员，测试推送、自动化提交和日常开发可能让不相关人员持续收到邮件；同时，邮件正文还可能暴露仓库名、提交说明或链接。

因此，迁移前先准备专用测试收件目标和非敏感内容。不要用真实用户地址或含个人信息的提交说明测试。涉及测试数据隐私时，可先核对本站的隐私说明，并仅将不含敏感仓库内容的邮件用于收件验收。

第一阶段：确定 GitHub Actions push 工作流的边界

Actions 工作流由仓库中的 YAML 文件定义，通常放在 .github/workflows 目录。一次事件发生后，GitHub 会按关联的提交和 Git 引用检查对应的工作流文件；若目标分支上的版本没有该文件，不能假设工作流会按预期启动。(GitHub Actions 工作流文档)

先把分支筛选写得足够窄。下面的片段仅示意：只在 main 和 release/ 下的分支触发；应按实际发布分支调整。

name: Push mail notification

on:
  push:
    branches:
      - main
      - 'release/**'

permissions:
  contents: read

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Send notification
        env:
          SMTP_HOST: ${{ secrets.SMTP_HOST }}
          SMTP_USER: ${{ secrets.SMTP_USER }}
          SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}
          NOTICE_TO: ${{ secrets.NOTICE_TO }}
        run: python scripts/send_push_notice.py

这是触发和凭据传递的骨架，不是完整邮件客户端：scripts/send_push_notice.py 必须由仓库维护者实现或接入获授权的发送程序，并按所选邮件服务的要求设置连接加密、发件人和收件人。不要把密码直接写进 YAML、脚本或命令行日志。

branches 是按分支名筛选；如果只设置了分支过滤，工作流不会因此自动响应标签推送。分支和标签筛选不能混为一谈，提交前应对照 GitHub Actions 工作流语法中的 push 筛选规则。

分支筛选配置后，怎样确认触发范围符合预期？ 在获授权的测试仓库或测试分支上，分别推送一笔符合规则和一笔不符合规则的测试变更。检查 Actions 运行记录中的触发事件与 GITHUB_REF，确认前者运行、后者不运行；不要用生产分支上的无关提交试筛选。GitHub 对 push 事件提供触发分支对应的 ref，可用来核对运行指向。(GitHub Actions 上下文参考)

第二阶段：收件对象、凭据与内容都要受控

确定一封通知发给谁、包含什么，再配置发送凭据。先用专用测试收件地址；主题和正文只保留验收必需的信息，例如仓库标识、分支、提交短标识和运行链接。不要放令牌、环境变量、差异内容或不必要的仓库信息。

将 SMTP 主机、用户名、密码和测试收件地址放在 Actions secrets 或适当的环境级 secrets 中。权限按最小必要原则设置：GitHub 提醒，拥有仓库写入权限的用户可读取该仓库配置的 secrets，因此自动脱敏不应被当作防止泄漏的安全边界。避免在脚本中打印环境变量，也不要把密钥拼进调试输出。(GitHub Actions 安全使用说明)

官方列出的限制中，仓库级 secrets 最多 100 个，单个 secret 不超过 48 KB。这些是容量上限，不是建议把凭据集中堆进仓库的理由；本通知通常只需要发送端必需的少数凭据。(GitHub Actions secrets 文档)

工作流显示成功却没有看到邮件时，应该按什么顺序排查？ 按链路逐层排查，不要先把“成功”当成“收件成功”：先确认运行对应的仓库、事件和分支；再看发送脚本是否执行、发送服务返回什么；随后检查收件地址拼写、垃圾邮件目录、隔离区和退信。最后用同一测试收件箱重发一封内容安全的测试信，避免同时改多个变量而无法定位原因。

第三阶段：分别验收触发、发送与实际收件

验收环节	可以证明什么	不能单独证明什么
Actions 运行记录	事件符合配置，工作流执行到了相应步骤	邮件已被发送端接受，或已进入收件箱
发送程序或邮件服务结果	发送步骤得到的响应及失败信息	收件箱展示、垃圾邮件判定或最终用户可见
受控测试收件箱	测试地址实际收到对应邮件，可核对正文与链接	其他收件人、域名或后续推送都必然成功

发送端返回成功，也不等同于收件人已在收件箱看到邮件。SMTP 标准规定，接收服务器接受邮件后承担继续投递或转发的责任；这仍不是对最终收件箱位置的证明。验收必须打开受控收件箱，确认邮件确实存在，并检查它是否进入垃圾邮件或隔离区。(RFC 5321 对 SMTP 接受邮件后责任的说明)

测试邮件最好包含可关联本次事件的提交短标识、分支名和运行链接。对照工作流运行记录与邮件正文，确认内容对应当前推送，而不是前一次测试留下的旧邮件。一次验收记录至少分别写下：是否触发、发送端返回结果、是否实收，以及实收位置。不要只记录一个绿色运行状态。

怎样确认测试邮件已经实收，而非只得到发送端的成功响应？ 在受控收件箱中找到本次测试邮件，核对收件地址、主题、提交标识和链接；再确认它位于收件箱还是垃圾邮件目录。若只有发送端成功响应、没有收件箱中的邮件证据，实收验收仍未通过。

第四阶段：核对异常分支与重复发送风险

迁移完成前，要验证反向路径：向不符合筛选条件的测试分支推送时，不应产生通知运行；符合条件的推送则应只生成预期的通知。检查 YAML 过滤规则、是否同时配置了多种事件，以及发送脚本是否会在重试时重复发信。

留意自动化提交引起的再次触发。如果通知工作流本身又推送了文件或提交，后续行为可能再次匹配触发条件；先确认该类提交是否可能发生，再决定是否排除特定分支或路径。失败时保留足以定位问题的信息，例如事件类型、分支、发送步骤结果和错误类别；日志中不要记录密码、令牌或完整敏感正文。

验收记录可按下面的项目逐项勾选：

[ ] 已确认需要替代的是仓库 Push 原生邮件通知，而非其他通知类型。
[ ] 已列出允许通知的仓库、分支与提交范围。
[ ] 工作流文件已存在于目标推送所对应的分支版本中。
[ ] 符合筛选条件的测试推送触发了预期工作流。
[ ] 不符合筛选条件的测试推送没有误触发通知。
[ ] 发送凭据存放在受控 secrets 中，日志未暴露凭据。
[ ] 发送结果与本次提交、工作流运行记录能够相互对应。
[ ] 受控测试收件箱中找到了本次邮件，并核对了内容与所在目录。
[ ] 已复核重试、自动化推送和重复邮件的可能性。

结束迁移前，保留清晰的通过标准

把“工作流成功”“发送端接受”“测试邮件实际收件”作为三个独立检查项。只要收件箱实收没有证据，就不要宣布通知链路验收通过；只要分支筛选或凭据管理仍不清楚，也不要把迁移扩到更多仓库。

如果只是测试自家仓库的通知，可用受控测试收件地址验证真实收件，并先确保邮件不含敏感仓库信息。需要把邮件转到长期使用的主邮箱时，应先了解邮件转发的适用方式；这不能替代工作流的发送配置，也不能代替实收核对。若希望为一次性测试减少主邮箱暴露，可在确认内容安全后试用 Fwdaway 提供的临时收件方式；银行、支付、政务或需要长期找回的账户，仍应使用可长期控制的邮箱。