Help us learn about your current experience with the documentation. Take the survey.

Danger 机器人

GitLab CI/CD 管道包含一个 danger-review 作业，它使用 Danger 对测试中的代码执行各种自动化检查。

Danger 是一个在 CI 环境中运行的 gem，就像其他分析工具一样。它区别于（例如，RuboCop）的地方在于，它被设计成允许你轻松编写任意代码来测试你的代码或更改的属性。为此，它提供了一组通用辅助方法和对你环境中实际发生更改的信息的访问权限，然后运行你的代码！

如果 Danger 要求你对合并请求进行某些更改，最好直接进行更改。如果你想了解 Danger 的工作原理，或者对现有规则进行修改，那么本文档就是为你准备的。

合并请求中的 Danger 评论

Danger 只发布一条评论，并在后续的 danger-review 运行中更新其内容。因此，它通常是合并请求中的前几条评论之一，如果不是第一条的话。如果你没有看到它，试着从合并请求的开头查看。

优点

  • 每次 danger-review 运行时，你不会收到电子邮件通知。

缺点

  • Danger 更新旧评论并不明显，因此你需要注意它是否被更新。
  • 当 Danger 令牌轮换时，会造成混乱/杂乱（因为旧评论无法更新）。

在本地运行 Danger

可以使用以下 Rake 任务在本地运行当前检查的一部分：

bin/rake danger_local

操作

启动时，Danger 从项目根目录读取一个 Dangerfile。GitLab 中的 Danger 代码被分解为一组辅助方法和插件，所有这些都位于 danger/ 子目录中，所以我们的代码只是告诉 Danger 加载所有内容。然后 Danger 针对合并请求运行每个插件，收集每个插件的输出。插件可能会输出通知、警告或错误，所有这些都会被复制到 CI 作业的日志中。如果发生错误，CI 作业（以及整个管道）就会失败。

在合并请求中，Danger 还会将输出复制到 MR 本身的评论中，以提高可见性。

开发指南

Danger 代码是 Ruby 代码，因此我们所有的常规后端指南仍然适用。然而，有几件事值得特别强调。

何时使用 Danger

Danger 是一个强大而灵活的工具，但并不总是解决特定问题或工作流程的最合适方式。

首先，请了解 GitLab 对自用（dogfooding）的承诺。我们为 Danger 编写的代码是 GitLab 特定的，它可能不是实现我们遇到的需求功能的最合适场所。毕竟，我们的用户、客户，甚至我们自己的卫星项目，如 Gitaly，经常面临类似的挑战。想想你如何能够在确保每个人都能从这项工作中受益的同时满足相同的需求，如果可以的话，就那么做吧。

如果某个任务有标准工具（例如，RuboCop），最好直接使用它，而不是通过 Danger 调用它。如果不涉及 Danger，在本地运行和调试这些工具的结果会更容易，而且除非你使用一些 Danger 特定的功能，否则将其包含在 Danger 运行中没有任何好处。

Danger 非常适合原型设计和快速迭代解决方案，因此如果我们想要构建的内容不明确，Danger 中的解决方案可以被视为一次试运行，以收集有关产品区域的信息。如果你正在这样做，请确保你尝试解决的问题以及该原型设计的成果都被记录在问题或史诗中。这有助于我们在 GitLab 的未来版本中将此需求作为产品的一部分来解决！

实现细节

将每个任务实现为一个独立的功能单元，并将其放在 danger 下的自己的目录中，格式为 danger/<task-name>/Dangerfile。

每个任务应该与其他任务隔离，并且能够独立运行。如果有代码应该在多个任务之间共享，请将其添加到 danger/plugins/... 中，并在每个需要它的任务中引用它。你还可以创建特定于单个任务的插件，这是与该任务相关的复杂逻辑的自然存放位置。

Danger 代码只是 Ruby 代码。它应该遵循我们的编码标准，并且需要测试，就像我们代码库中的任何其他 Ruby 代码一样。然而，我们无法直接测试 Dangerfile！因此，为了最大化测试覆盖率，尽量减少 danger/ 中的代码行数。一个非平凡的 Dangerfile 应该主要调用插件代码，其参数来自 Danger 提供的方法。插件代码本身应该有单元测试。

目前，我们通过将代码放在 tooling/danger/... 中的模块里，然后将其包含在相应的 danger/plugins/... 文件中来实现这一点。然后可以在 spec/tooling/danger/... 中添加规范。

要确定你的 Dangerfile 是否有效，请将包含它的分支推送到 GitLab。这可能相当令人沮丧，因为它在开发新任务或尝试调试现有任务中的问题时，显著增加了周期时间。如果你遵循了上述指南，你的大部分代码都可以在 RSpec 中本地运行，从而最小化你在 CI 中需要经历的周期次数。然而，你可以通过清空合并请求中的 .gitlab/ci/rails.gitlab-ci.yml 文件来稍微加快这些周期。只是在合并之前不要忘记恢复更改！

通过 Danger 添加标签

这适用于所有使用 gitlab-dangerfiles gem 的项目。

Danger 通常通过添加标签来改善 MR 的规范性。不要在 Dangerfile 中直接调用 API，而是将标签添加到 helper.labels_to_add 数组中（使用 helper.labels_to_add << label 或 helper.labels_to_add.concat(array_of_labels)）。gitlab-dangerfiles 将负责在所有规则有机会添加到 helper.labels_to_add 后，通过一次 API 调用将标签添加到 MR。

共享规则和插件

如果你实现的规则或插件对其他项目有用，考虑将其添加到上游的 gitlab-dangerfiles 项目中。

在项目中启用 Danger

要在另一个现有的 GitLab 项目上启用 Dangerfile，请完成以下步骤：

  1. Add gitlab-dangerfiles to your Gemfile.

  2. 创建一个包含以下内容的 Dangerfile：

    require "gitlab-dangerfiles"

Gitlab::Dangerfiles.for_project(self, &:import_defaults)

  3. 将以下内容添加到你的 CI/CD 配置中：

    include:
  - component: ${CI_SERVER_FQDN}/gitlab-org/components/danger-review/danger-review@1.2.0
    rules:
      - if: $CI_SERVER_HOST == "gitlab.com"

  4. 创建一个具有 api 范围、Developer 权限（以便它可以添加标签）和无过期日期（实际上意味着一年）的项目访问令牌。

  5. 将令牌作为名为 DANGER_GITLAB_API_TOKEN 的 CI/CD 项目变量添加。

在发送合并请求进行审查之前，你应该添加 ~“Danger bot” 标签。

当前用途

以下是迄今为止 Danger 在 GitLab 中被用于的各种事情的（非详尽）列表：

  • Coding style

  • Database review

  • Documentation review

  • Merge request metrics

  • Reviewer roulette

  • Single codebase effort

  • 代码风格

  • 数据库审查

  • 文档审查

  • 合并请求指标

  • 审查者轮盘

  • 单一代码库努力

已知问题

当你在个人分支上工作时，Danger 会运行，但其输出不会添加到合并请求评论中，也不会应用标签。这是因为来自原始项目的秘密变量没有共享到分支中。

最佳和推荐的方法是从已经配置好 Danger 的社区分支工作。

为个人分支配置 Danger

贡献者可以通过以下步骤为他们的分支配置 Danger：

  1. Create a personal API token that has the api scope set (don’t forget to copy it to the clipboard).

  2. 在你的分支中，添加一个名为 DANGER_GITLAB_API_TOKEN 的项目 CI/CD 变量，使用上一步复制的令牌。

  3. Make the variable masked so it doesn’t show up in the job logs. The variable cannot be protected, because it needs to be present for all branches.

  4. 使变量被屏蔽，这样它就不会出现在作业日志中。该变量不能被保护，因为它需要存在于所有分支中。