Discourse 代码审查

:discourse2: 摘要 Discourse 代码审查 允许在 Discourse 上审查 GitHub 提交。
:hammer_and_wrench: 仓库链接 https://github.com/discourse/discourse-code-review
:open_book: 安装指南 如何在 Discourse 中安装插件

功能

它是什么?

Discourse 代码审查插件提供了与 GitHub 代码仓库的双向集成。它允许您的团队利用 Discourse 的功能和插件(如分配、悄悄话、通知、自定义工作流等)来审查仓库的提交。每次对仓库的提交都会成为一个主题。对主题的回复会同步镜像到 GitHub。集成是双向的,这意味着您可以在 Discourse 上评论并在 GitHub 中看到,或者在 GitHub 上评论并在 Discourse 中看到。

它为需要审查任意数量仓库所有提交的团队提供了一个非常强大的工作流。

它使您能够确保多名团队成员了解应用到仓库的所有更改。您可以标记需要后续跟进的提交,分配审查工作等。

注意:当查看可以批准的提交主题时,您可以使用键盘上的 y 按钮来更快地批准提交。

我能看到实际效果吗?

Discourse 维护着 https://review.discourse.org/ 网站,该网站是公开的,任何人都可以使用 GitHub 凭证注册。该网站仅向非工作人员展示部分功能。一个更完整的示例可能如下:

在 GitHub 上,同一主题看起来是这样的:

配置

该插件依赖 GitHub Webhook 来发现仓库及其更改。对于最小化配置,您需要将以下设置设置为一个秘密字符串。

code review github webhook secret

一旦在您的 GitHub 仓库上设置,请配置一个 Webhook,参数如下:

Payload URL: https://YOUR_DISCOURSE/code-review/webhook
Content Type: application/json
Secret: code review github webhook secret 的值
事件类型:

  • 提交评论
  • 问题评论
  • 拉取请求
  • 拉取请求审查
  • 拉取请求审查评论
  • 推送

该插件提供以下额外的站点设置:

code review api username:GitHub 对匿名 API 请求的数量限制非常严格,此设置允许您使用 Discourse 用户的账户密钥进行 /comments/commit 请求。这大大降低了触及速率限制的几率。

code review catch up commits:当您遇到新仓库时,需要“追赶”并为其创建主题的提交数量。

code review default parent category:为插件创建的类别选择一个默认父类别。

code review pending tag:应用于所有未审查提交的标签,默认为 pending

code review approved tag:应用于已批准提交的标签,默认为 approved

code_review_followup_tag:应用于后续跟进提交的标签,默认为 follow-up

code review allow self approval:是否允许工作人员批准自己的提交?

code review default mute new categories:代码审查创建的新类别默认对用户静音。

code review skip duration minutes:点击提交上的跳过按钮将阻止该提交在由该设置指定的分钟数内再次显示。

更新日志

待办事项

额外信息

Discourse 如何使用此插件

TL;DR - 此插件旨在补充 Discourse 团队使用 GitHub 进行代码审查的工作方式。

更多信息

来自 @sam

  • 我们仍然使用 GitHub UI 进行拉取请求(PR),并且非常喜欢为大量更改进行 PR。这里没有任何改变。GitHub 很棒,我们热爱 GitHub。他们为尚未上线的更改提供了出色的工作流。然而…

  • GitHub 针对已直接提交到仓库的更改的工作流非常糟糕。

  • 审查填补了 GitHub 目前无法填补的空白,我们希望至少有一名团队成员审查对我们各个 Discourse 拥有的 git 仓库所做的每一次更改。如果我们使用 GitHub 提供的 UI,没有人永远被允许做任何事情,除了拉取请求。这将极大地拖慢我们的速度。

  • 我们需要一种能力,可以在某些更改方面进行私下沟通,而无需全世界都知道。例如:我们最好尽快将这个很棒的修复部署到 <insert giant company name>@sam 你能处理一下吗?

  • 我们需要能够批准所做的更改或请求后续跟进,这是 GitHub UI 无法提供的功能。

  • 我们需要能够将特定提交分配给某个用户。比如 @sam 做了一个包含一些错误的提交 containing some mistakes。我们可以直接分配他那个特定的提交,标记为需要跟进,然后持续跟踪其跟进情况,这很好。

  • Discourse 在对话方面非常棒,这些小功能带来了很大的不同,我可以看到人们在输入。我不需要刷新页面就能看到更改。引用功能很好,图片上传很好,等等。

  • Discourse 在读取状态方面做得很好,您会获得非常强的保证,即您阅读了每一件事一次,而在 GitHub 上,我不知道我读了哪些提交,哪些没读。我们有一种极其高效的方法来应对信息洪流。

列表还在继续…

因此,审查作为 GitHub 的补充,我们目前使用 GitHub 来处理尚未上线的更改。而我们使用审查来正确处理已经上线的更改。

70 个赞

我试图了解这个插件的用途。我有一种预感,我需要类似的东西,但我很难看出它如何提高效率。当有人批准一个拉取请求并将其合并到一个分支时,你们的流程中有什么使得该批准还需要对关联的提交进行另一次批准?

GitHub 不提供与提交相关的此功能,因为假设这已经在拉取请求中处理过了。我错过了什么?

是因为你们团队中有一些人可以批准拉取请求,但没有资格就实际发布做出最终决定吗?这样做的目的是为了能够快速合并和审查拉取请求,而不必等待最终拍板的人,并确保该人员或团队在创建发布之前会审查提交?

或者主要是为了支持公共仓库上的私人讨论?

我很想更多地了解在此插件在你们工作流程中的好处。谢谢!

这主要是 Discourse 早期工作流程的遗留物。

以前,我们用它来追溯性地批准变更集。

现在,所有内容都通过 PR 渠道进行,所以我们实际上并没有过多使用该插件。

1 个赞