Discourse 代码审查

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

功能

这是什么?

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

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

它允许您确保多名团队成员了解应用于仓库的所有更改。您可以标记提交以进行后续处理,分配审查工作等。

注意:在查看可以批准的提交时,您可以使用键盘上的 y 键更快地批准提交。

我能看到它的实际效果吗?

Discourse 在内部使用此插件来跟踪仓库。您可以在此处查看 Discourse 端的一个示例:

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

配置

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

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 的值
Event Types:

  • Commit comments
  • Issue comments
  • Pull requests
  • Pull request reviews
  • Pull request review comments
  • Pushes

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

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 创建的新分类默认对用户静音

code review skip duration minutes: 点击提交上的跳过按钮将阻止该提交再次显示,持续的时间由此设置中的分钟数决定。

更新日志

待办事项

附加内容

Discourse 如何使用此插件

简而言之 - 此插件旨在补充 Discourse 团队使用 GitHub 进行代码审查。

更多信息

来自 @sam

  • 我们仍然使用 GitHub UI 进行 PR,并且喜欢对大量更改进行 PR。这方面没有任何改变。GitHub 很棒,我们喜欢 GitHub。它们对于尚未落地的更改拥有出色的工作流。然而…

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

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

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

  • 我们需要能够批准所做的更改或请求后续处理,这是 GitHub UI 没有提供的功能。

  • 我们需要能够将特定的提交指派给用户。假设 @sam 做了一个提交 包含一些错误,很高兴我们可以直接将该特定提交指派给他,将其标记为后续处理,然后跟踪其后续处理情况。

  • Discourse 在处理整个对话方面非常出色,这些小功能带来了很大的不同,我可以看到谁正在输入。我从来不需要刷新页面就能看到更改出现。引用功能很好,图片上传也很好,等等。

  • Discourse 在已读状态方面做得很好,您会得到非常强的保证,即您只阅读了每一样东西一次,而在 GitHub 上,我不知道我读了哪些提交,没读哪些。我们拥有极其高效的机制来应对信息洪流。

列表还在继续…

所以 review 作为 GitHub 的补充,我们目前使用 GitHub 来处理尚未落地的更改。而我们使用 review 来正确处理已经落地的更改。

72 个赞

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

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

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

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

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

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

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

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

1 个赞