Oidrune 是部署在 Cloudflare 上的 GitHub Actions 通知网关，把调用仓库的 OIDC 身份验证、事件接收、Telegram 投递和运营控制收束到一个无需共享调用方密钥的入口。接入方只需复用固定版本 workflow 并授予 id-token: write，网关负责 owner/repository allowlist、可信 workflow SHA、持久化接收、自动重试和死信。运营者可以在控制台围绕接收记录、投递尝试与最终 delivered 状态排查通知链路。
正在加载正文…
Oidrune 是一个部署在 Cloudflare 上的 GitHub Actions 通知网关。
由 Oidrune 反向与 GitHub 验证调用方是否可信，大幅度简化新项目集成 Telegram 通知的配置，可实现零配置增加项目。
接入仓库只需调用固定版本的可复用 workflow，并授予 GitHub OIDC 所需的 id-token: write 权限。就能将结构化通知异步投递到由运营者控制的一个 Telegram 私聊、群组或频道。
最近在个人仓库内创建项目比较多，实在是受不了要给每个仓库的工作流配置通知服务，只有 GitHub 组织才能有共享的 secrets，但我不是很想为了这事创建组织。
调研了一下，发现 GitHub 支持签名的 OIDC token，这代表着 GitHub 天然提供了可信的事件发送信号，那么中继 webhook 到 Telegram 就闭环了。
为了提升可靠性，我选择了 Cloudflare Worker 提供稳定的中继服务，避免自托管中继服务导致服务中断。
公共入口只接受 GitHub 签名的 OIDC token，并根据获批的 owner 或 repository 进行校验。入口还结合可信 workflow release SHA 和 GitHub-hosted runner 约束通知来源，把调用方的信任边界收窄到可审计的工作流身份。
公共协议入口保持在 /v1/events/workflow-completed。Cloudflare Access 只保护 /console* 与 /api/admin*，不把 OIDC 事件接收和运营控制台混成同一条访问路径。
Oidrune 以持久化接收记录承接事件，再通过异步队列尝试发送通知。自动重试和死信队列保留失败事件的处理边界，运营者可以围绕接收、投递尝试和最终状态判断通知链路，而不需要把 Telegram 凭据下放给每个调用仓库。
运营控制台和管理员 API 使用 GitHub-only 的 Cloudflare Access 身份。仓库同时保留一个手动触发的 Oidrune smoke workflow，用 GitHub OIDC 调用固定 SHA 的通知 workflow，验证公共网关返回 202，并继续核对对应事件是否最终由队列消费者记录为 delivered。