GitHub 上的应用程序允许您自动化并改进工作流程。 可以生成应用来改进工作流。
GitHub 应用程序是官方推荐的与 GitHub 集成的方式,因为它们提供更精细的数据访问权限,但 GitHub 支持 OAuth Apps 和 GitHub Apps。 有关选择应用类型的信息,请参阅“GitHub 应用和 OAuth 应用之间的差异”。
有关生成 GitHub App 的过程演练,请参阅“在应用程序中使用 GitHub API”。
关于 GitHub Apps
GitHub Apps 是 GitHub 中的一流产品。 GitHub App 应用程序以自己的名义运行,通过 API 直接使用自己的身份进行操作,这意味着您无需作为独立用户维护自动程序或服务帐户。
GitHub Apps 可以直接安装在组织和个人帐户上,并获得对特定仓库的访问权限。 它们拥有内置 web 挂钩和狭窄的特定权限。 设置 GitHub App时,可以选择希望它访问的仓库。 例如,可以设置一个名为在存储库中MyGitHub
写入问题且octocat
仅写入存储库的应用octocat
。 要安装 GitHub App,您必须是组织所有者或在仓库中具有管理员权限。
默认情况下,只有组织所有者才可管理组织中 GitHub 的设置。 若要允许其他用户更改组织拥有的 GitHub 应用的开发人员设置,所有者可以向他们授予 GitHub 应用管理器权限。 GitHub 应用管理器无法管理第三方应用程序。 有关在组织中添加和删除 GitHub 应用管理器的详细信息,请参阅“组织中的角色”。
GitHub Apps 是需要托管在某处的应用程序。 有关涵盖服务器和托管的详细说明,请参阅“在应用程序中使用 GitHub API”。
要改进自己的工作流程,可以创建一个包含多个脚本或整个应用程序的 GitHub App,然后将此应用程序连接至许多其他工具。 例如,您可以将 GitHub Apps 连接至 GitHub、Slack、自己可能拥有的其他内部应用程序、电子邮件程序或其他 API。
创建 GitHub Apps 时,请记住以下方法:
-
GitHub App 的操作应独立于用户(除非此应用使用用户访问令牌)。 为使用户到服务器的访问令牌更安全,您可以使用将在 8 小时后过期的访问令牌,以及可交换新访问令牌的刷新令牌。 有关详细信息,请参阅“刷新用户访问令牌”。
-
请确保 GitHub App 与特定仓库集成。
-
GitHub App 应该连接到个人帐户或组织。
-
不要指望 GitHub App 知道并尽其所能。
-
如果您只需要“使用GitHub登录”服务,请不要使用 GitHub App。 但是 GitHub App 可以生成用户访问令牌来让用户登录和执行其他操作。
-
如果只想充当 GitHub 用户并执行用户所能执行的所有操作,请不要生成 GitHub App。
若要开始开发 GitHub Apps,请从“创建 GitHub 应用程序”开始。
关于 OAuth Apps
OAuth2 是一种协议,它允许外部应用程序请求授权在不使用密码的情况下访问用户 GitHub 帐户中的私有信息。 此协议优先于基本验证,因为令牌可能仅限于特定类型的数据,用户可以随时撤销。
警告:从 OAuth App 撤销所有权限将会删除应用程序代表用户生成的所有 SSH 密钥,包括部署密钥。
OAuth App 使用 GitHub 作为身份提供程序以验证为授予应用程序访问权限的用户。 这意味着,当用户授予 OAuth App 访问权限时,将授权访问其帐户有权访问的所有存储库,以及他们所属的、未阻止第三方访问的任何组织。
如果要创建比简单脚本的处理范围更复杂的流程,构建 OAuth App 是一个很好的选择。 请注意,OAuth Apps 是需要托管在某处的应用程序。
创建 OAuth Apps 时,请记住以下几点:
- OAuth App 在所有 GitHub 中(例如,在提供用户通知时)应始终代表经身份验证的 GitHub 用户。
- 通过为经身份验证的用户启用“使用 GitHub 进行登录”,OAuth App 可用作身份提供程序。
- 如果您希望应用程序作用于单个仓库,请不要构建 OAuth App。 使用
repo
OAuth 作用域,OAuth Apps 可以作用于经身份验证用户的所有存储库。 - 不要构建 OAuth App 作为团队或公司的应用程序。 OAuth Apps 将验证为单个用户,因此,如果有人创建了 OAuth App 供公司使用,那么一旦他们离开公司,其他人将无法访问它。
有关 OAuth Apps 的详细信息,请参阅“创建 OAuth 应用程序”和“使用 OAuth 应用对 REST API 进行身份验证”。
Personal access tokens
personal access token 是一个字符串,其功能类似于 OAuth 令牌,可以通过作用域指定其权限。 personal access token 还与密码类似,但你能拥有很多令牌,而且可以随时撤销对每个令牌的访问权限。
例如,可以启用 personal access token 以写入存储库。 如果随后运行 curl
命令或编写在存储库中创建问题的脚本,则需要传递 personal access token 以进行身份验证。 可以将 personal access token 存储为环境变量,以免每次使用时都要输入。
使用 personal access tokens 时,请记住以下想法:
- 记得只能用此令牌代表您自己。
- 你可以执行一次性
curl
请求。 - 您可以运行个人脚本。
- 不要为整个团队或公司设置脚本。
- 不要设置共享个人账户以用作自动程序用户。
- 为令牌授予所需的最低特权。
- 为 personal access tokens 设置过期时间,以帮助确保信息安全。
确定要构建的集成
在开始创建集成之前,您需要确定使用 GitHub AE API 访问、验证和交互的最佳方式。
若要决定是使用 personal access tokens、GitHub Apps 还是 OAuth Apps 进行集成,请考虑以下有关集成需要如何运行以及它需要访问的内容的问题:
- 我的集成是只像我一样,还是更像一个应用程序?
- 我是否希望它作为单独的实体独立于我运行?
- 它是否能访问我可以访问的一切,或者说我想限制它的访问权限?
- 它是简单还是复杂? 例如,personal access token 对简单的脚本和
curl
命令有益,而 OAuth App 可以处理更复杂的脚本。
如果集成只扮演你的角色,但你希望限制其访问,请使用 GitHub App 或 fine-grained personal access token。
如果集成的运行方式更像应用程序,请考虑是否希望集成作为它自己的实体独立运行。 如果是,请使用 GitHub App。
请求支持
有关 GitHub Apps、OAuth Apps 和 API 开发的问题、漏洞报告和讨论,请访问 GitHub 社区上的 API 和集成讨论。 该讨论由 GitHub 工作人员管理和维护,但不能保证发布到论坛的问题都会得到 GitHub 工作人员的回复。
请考虑使用联系人表单直接联系 GitHub 支持:
- 要保证得到 GitHub AE 工作人员的回应
- 涉及敏感数据或私人问题的支持请求
- 功能请求
- 关于 GitHub AE 产品的反馈