使用 Mergify 与 Rush

Mergify 为 GitHub 提供一项附加服务，提供扩展的 **合并队列** 功能。如果您不熟悉合并队列，请从 Rush 文档中的最佳实践：启用合并队列和 Mergify 中的什么是合并队列以及为什么要使用它？开始。

优化队列的一般问题涉及许多权衡和启发式方法，用于选择哪些工作并行执行或组合。这为优化和实现者之间的差异化创造了许多机会。Mergify 的服务针对大型、高速的单体仓库。他们的合并队列基准测试提供了一个功能矩阵，突出显示了各种系统之间的差异。

基本示例

通常将 Mergify 配置文件命名为 .mergify.yml，它定义了大部分行为。让我们总结一下拉取请求的基本生命周期：一旦在您的仓库中创建了一个 PR，Mergify 将检测到它，并根据 pull-request-rules 进行检查。此规则集允许您自动化和调整各种工作流程。

pull-request-rules 包含条件和操作，特别是 queue 操作。一旦 PR 验证了拉取请求规则的条件，它将触发其操作，导致 PR 被排队。以下是一个示例配置文件

.mergify.yml

queue_rules:
  - name: default
    merge_conditions:
      - '#approved-reviews-by>=2'
      - check-success=Travis CI - Pull Request

pull_request_rules:
  - name: merge using the merge queue
    conditions:
      - base=main
      - label=queue
    actions:
      queue:

在上面，我们定义了一个名为 default 的唯一合并队列，它有自己的条件集。merge_conditions 需要在 PR 可以合并之前进行验证。

使用分区来提高并行度

优化合并队列的关键是识别可以在并行执行的作业，因为它们的 Git 差异是独立的。如果（1）它们的差异不涉及相同的文件，以及（2）两个差异“影响”的文件根据依赖关系图没有重叠，则两个 PR 是“独立”的。Rush 的依赖关系分析以 Rush 项目为粒度，而不是单个文件。就 Rush 项目选择器而言，这意味着 rush list --impacted-by git:origin/main 在两个 PR 之间必须没有任何重叠。

Mergify 的分区在此分析中类似于 Rush 项目；每个分区定义了一组文件，并能够声明分区之间的依赖关系，这可以确定作业是并行构建还是串行构建。

例如，假设您的 Rush 工作区包含三个名为 project-a、project-b 和 project-c 的项目。以下是一个示例硬编码配置

.mergify.yml

partition_rules:
  - name: project-a
    conditions:
      - files~=^apps/project-a

  - name: project-a
    conditions:
      - files~=^apps/project-a

  - name: project-a
    conditions:
      - files~=^apps/project-c

queue_rules:
  - name: default
    merge_conditions:
      - and:
          - or:
              - queue-partition-name!=project-a
              - check-success=ciA
          - or:
              - queue-partition-name!=project-a
              - check-success=ciB
          - or:
              - queue-partition-name!=project-a
              - check-success=ciC

pull_request_rules:
  - name: merge using the merge queue
    conditions:
      - base=main
      - label=queue
    actions:
      queue:

在这个例子中，如果一个 PR 修改了文件夹 project-a 下面的文件，那么用于检查和合并 PR 的分区和合并队列将自动是 project-a 的分区和合并队列。

如果一个 PR 同时修改了来自两个或多个项目的文件，那么 PR 将在每个对应的分区中进行检查。

在一个大型单体仓库中，手工编码 files~= 条件是不切实际的；它需要使用脚本生成。

💡即将推出
我们正在合作开发一个与供应商无关的 project-impact-graph.yaml 规范，以及一个配套的 Rush 插件，这将使 Mergify 等服务能够直接查询 rush.json 依赖关系图。

自动操作

Mergify 还包括一个工作流程自动化功能，可以自动执行添加评论、分配审阅者或添加标签等任务。例如

.mergify.yml

pull_request_rules:
  - name: comment on project-a pull request
    conditions:
      - files~=^apps/project-a
    actions:
      comment:
        message: This pull request modifies a file in project-a

  - name: assign review to a project-b reviewer
    conditions:
      - files~=^apps/project-b
    actions:
      assign:
        add_users:
          - projectb_reviewer

  - name: add label on project-c pull request
    conditions:
      - files~=^apps/projectC
    actions:
      label:
        toggle:
          - project-c

一些其他有用的操作

回退：将拉取请求复制到另一个分支，一旦它被合并。
更新：使用其基分支更新拉取请求分支。

另请参阅

最佳实践：启用合并队列来自 Rush 文档
Mergify 文档

基本示例​

使用分区来提高并行度​

自动操作​

另请参阅​

基本示例

使用分区来提高并行度

自动操作

另请参阅