OneUptime 与 GitHub 集成实战用 Workflow 将 Incident 自动转化为 GitHub Issue【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇指南讲解 OneUptime 的一项「出站」集成能力当监控平台产生一个新的 Incident事故时通过 Workflow 的「Incident → On Create」触发器与 API 组件自动在承载受影响的 Service 的 GitHub 仓库中创建一条 Issue实现监控事故与代码仓库技术跟踪的闭环。读完后你将掌握 Token 安全存储、Workflow 搭建、请求体模板变量、自托管部署下的网络放行要求以及常见 HTTP 错误的排查方法并能结合 OneUptime 源码理解 API 组件的入参、返回值与密钥脱敏机制。集成架构一条纯出站调用链该集成是**出站outgoing**的OneUptime 主动调用 GitHub REST API不需要 GitHub 向 OneUptime 发起任何回调。整体链路如下OneUptime Incident → On Create ──► API component (POST /repos/{owner}/{repo}/issues) ──► GitHub issue即事故创建事件触发 WorkflowWorkflow 中的 API 组件向 GitHub 发起POST /repos/{owner}/{repo}/issues请求最终在目标仓库中生成 Issue。注意与原生 GitHub App 的区分OneUptime 还有一项基于GitHub App的原生集成用于连接代码仓库服务于 AI Agent 与 Code 功能可以在 Issue 或 Pull Request 中 提及它来让 AI 实现、修改或审查代码详见 AI GitHub App 文档 与 自托管 GitHub 集成安装文档。而本页的主题聚焦于从 Incident 创建 GitHub Issue这一具体场景。前置条件一个用于创建 Issue 的 GitHub 仓库一个具备创建 Issue 权限的 Token二选一细粒度 PATFine-grained PAT将该 Token 限制到目标仓库并授予Issues: Read and write权限经典 PATClassic PAT授予repoScope。在 GitHub 的 Token 设置页面github.com/settings/tokens中创建一个有权限创建 Workflow 的 OneUptime 项目。第一步 — 保存 GitHub Token进入Workflows → Global Variables全局变量→ Create创建变量名命名为GITHUB_TOKEN填入 Token 内容并启用Is Secret密文开关。这一步在源码层面的支撑如下Workflow 执行时全局变量与局部变量会被分别装载进运行时存储。在 RunWorkflow.ts 中可以看到执行引擎会把globalVariables写入newStorageMap.global.variables、把localVariables写入newStorageMap.local.variables这正是模板语法{{variable.GITHUB_TOKEN}}能够被解析的前提将变量标记为 Secret 有实际安全意义API 组件定义 中request-headers参数被显式标记为isSensitive: true源码注释解释了原因——Header 正是填写 Authorization Bearer Token 的位置若不脱敏解析后的明文会被原样写进 WorkflowLog任何有该项目读权限的人都能看到。SecretRedaction.ts 负责在日志写入路径上把来自密文变量的值统一擦除scrub。因此务必启用 Is Secret否则 Token 可能泄漏到运行日志中。第二步 — 创建 Workflow打开Workflows → Create Workflow创建 Workflow命名为Incidents → GitHub Issues进入Builder可视化编辑器添加一个Incident事故触发器事件选择On Create创建时并将其重命名为Incident这个名字决定了后面模板变量{{Incident.title}}、{{Incident.description}}的引用前缀添加一个API组件并连接到触发器配置如下Method:POSTURL:https://api.github.com/repos/your-org/your-repo/issues替换为你自己的组织/仓库路径Headers:Authorization: Bearer {{variable.GITHUB_TOKEN}} Accept: application/vnd.githubjson X-GitHub-Api-Version: 2022-11-28 User-Agent: OneUptimeBody:{ title: OneUptime incident: {{Incident.title}}, body: {{Incident.description}}\n\nFiled automatically from OneUptime., labels: [incident, oneuptime] }保存并启用 Workflow然后创建一条测试 Incident。在 Workflow 日志中看到201 Created即表示 Issue 创建成功GitHub 返回的 Response Body 中会包含该 Issue 的number与html_url字段。API 组件的源码级说明上面用到的「API 块」在 OneUptime 中对应一组内置组件其元数据定义在 API.tsCommon/Types/Workflow/Components/API.ts包含API Get (JSON)、API Post (JSON)、API Put (JSON)、API Patch (JSON)、API Delete (JSON)五个组件。其中本场景使用的是API Post (JSON)ComponentID.ApiPost其定义印证了文档中的配置项与返回值类别字段说明入参url请求地址必填URL 类型入参request-bodyJSON 请求体可选入参request-headers字符串字典可选、高级选项isSensitive: true返回值error如有错误则为错误信息返回值response-status响应状态码数字如200、201返回值response-headers响应头返回值response-body响应体JSON即验证时读取number/html_url的来源端口In/Success/Error输入端口与两个分支输出端口可用于成功/失败后的流程分叉也就是说文档中「看到201 Created」对应的是response-status返回值「Response Body 中包含number和html_url」对应的是response-body返回值二者都是组件的正式定义字段而非约定俗成。进阶用法GitHub Enterprise Server将 API 地址替换为https://your-host/api/v3/repos/{owner}/{repo}/issues指派负责人 / 关联里程碑在 Body 中追加assignees: [octocat]或milestone: 3回写反向链接读取{{CreateIssue.response-body.html_url}}再通过一个Update Incident组件把 Issue 链接写回事故记录实现监控侧与代码侧的双向可追溯。故障排查状态码原因与处理401Token 错误或已过期。细粒度 PAT 必须显式指定该仓库并授予Issues权限403/ Rate Limit确认请求包含User-Agent头GitHub 会拒绝未带该头的请求并检查是否触达 API 速率限制404owner/repo路径拼写错误或 Token 无权访问该私有仓库422引用不存在的 Label 不是问题GitHub 会自动创建被引用的 Label但请求体 JSON 本身不合法会导致 422——检查 Body 的 JSON 格式排查时建议直接查看 Workflow 运行日志结合 API 组件的response-status与response-body返回值可以定位是鉴权问题、路径问题还是请求体问题。自托管部署下的网络访问要求本集成中创建 Issue 的 Workflow 需要 OneUptime 到api.github.com的DNS 解析与出站 HTTPSTCP 443连接能力不需要任何来自 GitHub 的入站回调。关于出站连接、入站回调与私有部署的详细网络策略见 自托管 GitHub 集成文档 中的网络访问章节。相关主题集成总览 — 集成模式与鉴权速查表GitLab 集成 — 同样的原理应用于 GitLabWorkflows 文档 — Workflow 触发器、组件与模板语法的整体介绍AI GitHub App 文档 — 从 Issue 或 Pull Request 中直接驱动 OneUptime 的 AI 能力API 组件元数据 — 本文所用 API 组件的入参、返回值与端口定义Workflow 执行引擎 — 全局/局部变量装载与日志记录的实现密钥脱敏工具 — 运行日志中密文变量的擦除逻辑【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 与 GitHub 集成实战：用 Workflow 将 Incident 自动转化为 GitHub Issue
OneUptime 与 GitHub 集成实战用 Workflow 将 Incident 自动转化为 GitHub Issue【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本篇指南讲解 OneUptime 的一项「出站」集成能力当监控平台产生一个新的 Incident事故时通过 Workflow 的「Incident → On Create」触发器与 API 组件自动在承载受影响的 Service 的 GitHub 仓库中创建一条 Issue实现监控事故与代码仓库技术跟踪的闭环。读完后你将掌握 Token 安全存储、Workflow 搭建、请求体模板变量、自托管部署下的网络放行要求以及常见 HTTP 错误的排查方法并能结合 OneUptime 源码理解 API 组件的入参、返回值与密钥脱敏机制。集成架构一条纯出站调用链该集成是**出站outgoing**的OneUptime 主动调用 GitHub REST API不需要 GitHub 向 OneUptime 发起任何回调。整体链路如下OneUptime Incident → On Create ──► API component (POST /repos/{owner}/{repo}/issues) ──► GitHub issue即事故创建事件触发 WorkflowWorkflow 中的 API 组件向 GitHub 发起POST /repos/{owner}/{repo}/issues请求最终在目标仓库中生成 Issue。注意与原生 GitHub App 的区分OneUptime 还有一项基于GitHub App的原生集成用于连接代码仓库服务于 AI Agent 与 Code 功能可以在 Issue 或 Pull Request 中 提及它来让 AI 实现、修改或审查代码详见 AI GitHub App 文档 与 自托管 GitHub 集成安装文档。而本页的主题聚焦于从 Incident 创建 GitHub Issue这一具体场景。前置条件一个用于创建 Issue 的 GitHub 仓库一个具备创建 Issue 权限的 Token二选一细粒度 PATFine-grained PAT将该 Token 限制到目标仓库并授予Issues: Read and write权限经典 PATClassic PAT授予repoScope。在 GitHub 的 Token 设置页面github.com/settings/tokens中创建一个有权限创建 Workflow 的 OneUptime 项目。第一步 — 保存 GitHub Token进入Workflows → Global Variables全局变量→ Create创建变量名命名为GITHUB_TOKEN填入 Token 内容并启用Is Secret密文开关。这一步在源码层面的支撑如下Workflow 执行时全局变量与局部变量会被分别装载进运行时存储。在 RunWorkflow.ts 中可以看到执行引擎会把globalVariables写入newStorageMap.global.variables、把localVariables写入newStorageMap.local.variables这正是模板语法{{variable.GITHUB_TOKEN}}能够被解析的前提将变量标记为 Secret 有实际安全意义API 组件定义 中request-headers参数被显式标记为isSensitive: true源码注释解释了原因——Header 正是填写 Authorization Bearer Token 的位置若不脱敏解析后的明文会被原样写进 WorkflowLog任何有该项目读权限的人都能看到。SecretRedaction.ts 负责在日志写入路径上把来自密文变量的值统一擦除scrub。因此务必启用 Is Secret否则 Token 可能泄漏到运行日志中。第二步 — 创建 Workflow打开Workflows → Create Workflow创建 Workflow命名为Incidents → GitHub Issues进入Builder可视化编辑器添加一个Incident事故触发器事件选择On Create创建时并将其重命名为Incident这个名字决定了后面模板变量{{Incident.title}}、{{Incident.description}}的引用前缀添加一个API组件并连接到触发器配置如下Method:POSTURL:https://api.github.com/repos/your-org/your-repo/issues替换为你自己的组织/仓库路径Headers:Authorization: Bearer {{variable.GITHUB_TOKEN}} Accept: application/vnd.githubjson X-GitHub-Api-Version: 2022-11-28 User-Agent: OneUptimeBody:{ title: OneUptime incident: {{Incident.title}}, body: {{Incident.description}}\n\nFiled automatically from OneUptime., labels: [incident, oneuptime] }保存并启用 Workflow然后创建一条测试 Incident。在 Workflow 日志中看到201 Created即表示 Issue 创建成功GitHub 返回的 Response Body 中会包含该 Issue 的number与html_url字段。API 组件的源码级说明上面用到的「API 块」在 OneUptime 中对应一组内置组件其元数据定义在 API.tsCommon/Types/Workflow/Components/API.ts包含API Get (JSON)、API Post (JSON)、API Put (JSON)、API Patch (JSON)、API Delete (JSON)五个组件。其中本场景使用的是API Post (JSON)ComponentID.ApiPost其定义印证了文档中的配置项与返回值类别字段说明入参url请求地址必填URL 类型入参request-bodyJSON 请求体可选入参request-headers字符串字典可选、高级选项isSensitive: true返回值error如有错误则为错误信息返回值response-status响应状态码数字如200、201返回值response-headers响应头返回值response-body响应体JSON即验证时读取number/html_url的来源端口In/Success/Error输入端口与两个分支输出端口可用于成功/失败后的流程分叉也就是说文档中「看到201 Created」对应的是response-status返回值「Response Body 中包含number和html_url」对应的是response-body返回值二者都是组件的正式定义字段而非约定俗成。进阶用法GitHub Enterprise Server将 API 地址替换为https://your-host/api/v3/repos/{owner}/{repo}/issues指派负责人 / 关联里程碑在 Body 中追加assignees: [octocat]或milestone: 3回写反向链接读取{{CreateIssue.response-body.html_url}}再通过一个Update Incident组件把 Issue 链接写回事故记录实现监控侧与代码侧的双向可追溯。故障排查状态码原因与处理401Token 错误或已过期。细粒度 PAT 必须显式指定该仓库并授予Issues权限403/ Rate Limit确认请求包含User-Agent头GitHub 会拒绝未带该头的请求并检查是否触达 API 速率限制404owner/repo路径拼写错误或 Token 无权访问该私有仓库422引用不存在的 Label 不是问题GitHub 会自动创建被引用的 Label但请求体 JSON 本身不合法会导致 422——检查 Body 的 JSON 格式排查时建议直接查看 Workflow 运行日志结合 API 组件的response-status与response-body返回值可以定位是鉴权问题、路径问题还是请求体问题。自托管部署下的网络访问要求本集成中创建 Issue 的 Workflow 需要 OneUptime 到api.github.com的DNS 解析与出站 HTTPSTCP 443连接能力不需要任何来自 GitHub 的入站回调。关于出站连接、入站回调与私有部署的详细网络策略见 自托管 GitHub 集成文档 中的网络访问章节。相关主题集成总览 — 集成模式与鉴权速查表GitLab 集成 — 同样的原理应用于 GitLabWorkflows 文档 — Workflow 触发器、组件与模板语法的整体介绍AI GitHub App 文档 — 从 Issue 或 Pull Request 中直接驱动 OneUptime 的 AI 能力API 组件元数据 — 本文所用 API 组件的入参、返回值与端口定义Workflow 执行引擎 — 全局/局部变量装载与日志记录的实现密钥脱敏工具 — 运行日志中密文变量的擦除逻辑【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
