Skip to main content

Enterprise Server 3.15 目前作为候选发布提供。

Webhook 的类型

可以通过创建 Webhook 订阅特定存储库、组织、GitHub Enterprise、 或 GitHub App 中发生的事件。

关于 Webhook 类型

Webhook 仅可访问安装了 Webhook 的存储库,组织,GitHub Enterprise, 或 GitHub App 中的可用事件。

无法为单个用户帐户或特定于用户资源的事件(例如个人通知或提及)创建 Webhook。

要创建和管理 Webhook,必须拥有创建 Webhook 并侦听事件的资源或拥有该资源的管理员访问权限。 例如,需要组织的管理员权限才能管理组织 Webhook。

某些 Webhook 事件是某些类型的 Webhook 独有的。 例如,组织 Webhook 可以订阅仅在组织级别发生的事件,存储库 Webhook 无法订阅这些事件。 有关 Webhook 特定可用性的详细信息,请参阅“Webhook 事件和有效负载”。

有关详细信息,请参阅“关于 web 挂钩”。

仓库 web 挂钩

可以在存储库中创建 Webhook 以订阅在该存储库中发生的事件。 必须是存储库所有者,或在存储库中具有管理员访问权限的人员,才能在存储库中创建和管理 Webhook。 无法在没有所需权限的存储库中创建、编辑或删除 Webhook。

可以在单个存储库中创建多个 Webhook。 但是,仅能创建最多 250 个订阅各个事件类型 的 Webhook。 例如,在单个存储库中,仅能创建最多 250 个订阅 push 事件的不同 Webhook。

可以使用 GitHub Web 界面或 REST API 来管理存储库 Webhook。 有关详细信息,请参阅“创建 web 挂钩”、“测试 Webhook”和“禁用 Webhook”。 有关使用 REST API 来管理存储库 Webhook 的详细信息,请参阅“存储库 Webhook 的 REST API 终结点”。

组织 web 挂钩

可以在组织中创建 Webhook 以订阅在该组织中发生的事件。 组织 Webhook 可以订阅组织拥有的所有存储库中发生的事件。 还可以订阅在组织级别发生的任何特定存储库之外的事件,例如新成员加入组织。

必须是组织所有者才可以管理组织 Webhook。

可以在单个组织中创建多个 Webhook。 但是,仅能创建最多 250 个订阅各个事件类型 的 Webhook。 例如,在单个组织中,仅能创建最多 250 个订阅 push 事件的不同 Webhook。

可以使用 GitHub Web 界面或 REST API 来管理组织 Webhook。 有关详细信息,请参阅“创建 web 挂钩”、“测试 Webhook”和“禁用 Webhook”。 有关使用 REST API 来管理组织 Webhook 的详细信息,请参阅“适用于组织 Webhook 的 REST API 终结点”。

GitHub Enterprise

的全局 Webhook

企业所有者可以创建全局 Webhook 以订阅企业或企业拥有的组织和存储库中发生的事件。

可以在单个企业中创建多个 Webhook。 但是,仅能创建最多 250 个订阅各个事件类型 的 Webhook。 例如,在单个企业中,仅能创建最多 250 个订阅 membership 事件的不同 Webhook。

可以使用 GitHub Web 界面来管理全局 Webhook。 有关详细信息,请参阅“创建 web 挂钩”、“测试 Webhook”和“禁用 Webhook”。 你还可以使用 REST API 管理全局 Webhook。 有关端点的完整列表,请参阅“适用于全局 Webhook 的 REST API 终结点”。

GitHub App Webhook

可以将 GitHub App 配置为在已授予应用访问权限的存储库或组织中发生特定事件时接收 Webhook。

每个 GitHub App 都有一个 Webhook,该 Webhook 由 GitHub 自动创建。 默认情况下,Webhook 不会订阅任何事件。 可以配置 Webhook 订阅的事件。 GitHub App Webhook 无法删除,但停用即可停止接收 Webhook 交付。

可以使用 GitHub Web 界面或 REST API 来管理 GitHub App Webhook。 有关详细信息,请参阅“创建 web 挂钩”、“测试 Webhook”和“禁用 Webhook”。 有关使用 REST API 管理 GitHub App Webhook 的详细信息,请参阅“GitHub App Webhook 的 REST API 终结点”。