作为我们逐步迁移到 GitHub Apps 的一部分,我们正式宣布将弃用 GitHub 提交状态 API 更新,适用于 travis-ci.com 上由 GitHub Apps 管理的仓库。 相反,这些仓库将使用 GitHub 检查运行 API 报告状态更新。 从 **2018 年 10 月 4 日** 起,我们将不再为由 GitHub Apps 管理的仓库提供 GitHub 提交状态 API 更新。
您的工作流程很可能只在依赖 GitHub 受保护分支 或依赖 GitHub 提交状态 API 的自定义自动化时才会受到影响。
如果您的工作流程不属于上述两种情况,则更改的影响很小 - 除了弃用的(重复)GitHub 状态 API 更新将从您的拉取请求中消失。 如果您确实使用受保护分支或 GitHub 提交状态 API,我们有一些更新建议。
受保护分支是 GitHub 中的一项功能,可以让您阻止将拉取请求合并到特定分支,除非状态检查已通过。
如果您是仓库所有者,您可以使用受保护分支更新您的仓库以使用状态检查,方法如下:
设置
页面,然后选择 分支
分支保护设置
部分,单击受保护分支的 编辑
合并前要求状态检查通过
。 选择 Travis CI - 拉取请求
或 Travis CI - 分支
或两者。(注意: continuous-integration/travis-ci
是即将弃用的状态 API 事件)由于我们将不再使用 GitHub 提交状态 API,因此您构建或正在使用的自动化(包括依赖此 GitHub 端点的第三方集成)可能无法正常工作,除非状态 API 更新。
如果您正在管理与 GitHub 的集成,我们建议您切换到使用 GitHub 检查运行 API。 例如,您无需通过 GET
到 /repos/:owner/:repo/commits/:ref/statuses
获取提交状态,而是建议您使用以下端点
GET /repos/:owner/:repo/commits/:ref/check-runs
阅读 GitHub 检查运行 API 文档,以详细了解您可以预期的有效负载。
我们希望这些建议对您有所帮助! 如果您对 GitHub 提交状态 API 有严格的要求,而我们在本文中没有涵盖,请尽快发送电子邮件至 [email protected],以便我们在弃用过程中提供支持。
当然,如果您对这些更改有任何其他问题,或者我们能做些什么来帮助您,请在论坛 travis-ci.community 上告诉我们,或者向我们发送电子邮件。 非常感谢!