0

我遇到了一个合并顺序问题，即在对后来的更改（“101”）进行了代码审查之后，对 gerrit 更改（“100”作为参数）进行了代码审查。这导致 jenkins 构建和发布 gerrit ID“100”，之前从 gerrit ID“101”发布的代码不再是最新版本。

我想知道我是否有一个基本问题 - 我最初的想法是“选择策略：gerrit”对于 maven 验证是正确的，但是当我从 master 构建代码审查代码时应该是“选择策略：默认”。

我有以下 JJB 格式的 jenkins 配置，用于构建 master 并从中生成发布的作业：

parameters:
  - string:
      name: GERRIT_REFSPEC
      default: refs/heads/master
triggers:
  - gerrit:
      trigger-on:
        - change-merged-event
scm:
  - git:
      url: '{gerrit_url}/{repo}'
      credentials-id: '{gerrit_credentials_id}'
      name: origin
      refspec: $GERRIT_REFSPEC
      branches:
        - $GERRIT_BRANCH
      choosing-strategy: gerrit

更新（2018 年 4 月）：似乎正在发生的事情是，在用户对代码进行审查并合并到 master 的事件之后，传递给 Jenkins 的 GERRIT_REFSPEC 最终产生了补丁，即在它被合并到之前看起来的代码掌握。

因此，我最初认为是一个模糊的合并顺序问题，结果证明我们一开始只是构建了错误的东西。建议的选择策略提供了一个足够体面的工作，但我不确定我是否会称之为解决方案。

4

0 回答 0