我目前拥有一个机器人,可以自动执行一些GitHub操作,比如合并拉取请求、在 Slack 上通知工作人员等(这是一个定制化的 Hubot 实例)。
当工作人员命令它合并拉取请求时,它首先检查他们是否属于具有对该存储库的写访问权限的团队。这个功能是可行的,但代码不太好。
首先,它获取组织中的所有团队,遍历它们,获取分配给该团队的所有用户,如果找到发出合并命令的用户,则检查该团队是否具有写访问权限。如果没有,身份验证就不好了。
这是最好的方法吗?我觉得可能会简单得多。
我目前拥有一个机器人,可以自动执行一些GitHub操作,比如合并拉取请求、在 Slack 上通知工作人员等(这是一个定制化的 Hubot 实例)。
当工作人员命令它合并拉取请求时,它首先检查他们是否属于具有对该存储库的写访问权限的团队。这个功能是可行的,但代码不太好。
首先,它获取组织中的所有团队,遍历它们,获取分配给该团队的所有用户,如果找到发出合并命令的用户,则检查该团队是否具有写访问权限。如果没有,身份验证就不好了。
这是最好的方法吗?我觉得可能会简单得多。
更新:现在有一个GitHub API端点用于此操作:
https://docs.github.com/en/rest/reference/collaborators#check-if-a-user-is-a-repository-collaborator
旧答案:目前没有更简单的方法来做到这一点(但我同意,如果有更优雅的方法来获取这些信息将是很好的)。您可以通过获取用户的团队和具有对存储库访问权限的团队列表(而不是组织中的所有团队)来减少请求次数。这两个列表的交集应该能够回答这个问题,我想。
(此外,在您的解决方案中,请注意您不仅需要检查用户是否是推送访问团队的成员 - 您还需要检查此推送访问团队是否有权访问所需的存储库。用户可能是推送访问团队的成员,但该团队没有权限访问所需的存储库,而且他也可能是一个能够访问所需的存储库的拉取访问团队的成员。)
我的公司使用Github企业版。
这个API文档链接很有帮助。
GET /repos/:owner/:repo/collaborators/:username
如果用户有权限,你将会收到类似以下的响应:
状态:204 无内容
X-RateLimit-Limit:5000
X-RateLimit-Remaining:4999
/repos/:owner/:repo/collaborators
,查找与给定用户匹配的条目,然后检查 permissions
,但这种方法效率低下,特别是当分页强制您进行多个请求时。我联系了GitHub,一位代表同意他们可能会考虑专门用于此目的的API。 - Jesse Glick