BitBucket 没有更新 PR 的 refspec，导致 Jenkins 构建旧的提交

Question

我正在使用带有 Git 的本地 BitBucket 服务器。我正在尝试开始使用持续集成，所以我设置了一个本地 Jenkins 实例。目标是让 Jenkins 检查拉取请求并构建项目，然后将结果报告给 BitBucket。

在 BitBucket 中，我使用 Webhook to Jenkins for Stash，它会在每次创建/更新拉取请求时通知我的 Jenkins 实例。

在 Jenkins 中，当收到上述插件的通知时，我使用 Stash pullrequest builder plugin 让 Jenkins 签出 pullrequest。我已经使用了文档中的设置，即

Refspec: +refs/pull-requests/*:refs/remotes/origin/pr/*
Branch Specifier: origin/pr/${pullRequestId}/from

它几乎可以工作......

当我在 BitBucket 中创建新的拉取请求时，Jenkins 得到通知，检查 PR 并将结果报告回 BitBucket。到目前为止，一切都很好。

但是，当我更新 PR（即提交新代码并推送到 BitBucket）时，Jenkins 会被触发，但仍会检查 PR 中的先前提交，而不是新提交。

我进行了一些调查，但被卡住了。据我了解Refspec 指定我应该在本地将refs/remotes/origin/pr/* 映射到refs/pull-requests/*。但是，当我对现有 PR 进行新提交时，BitBucket 似乎不会更新 PR 的引用，这导致 Jenkins 只能找到旧的。

当我在提交更新并将更新推送到现有 PR 后运行 git ls-remote origin 时，我得到以下信息：

edf245 (new commit)...             refs/heads/feature/Name-Of-My-Branch-That-I-Created-Pull-Request-From-pr
af774f (previous commit in PR)...  refs/pull-requests/69/from
7fa82b (master)...                 refs/pull-requests/69/merge

然而，在访问 BitBucket 中的 PR 页面后，refs 似乎已更新，我得到以下结果：

edf245 (new commit)...             refs/heads/feature/Name-Of-My-Branch-That-I-Created-Pull-Request-From-pr
edf245 (new commit)...             refs/pull-requests/69/from
7fa82b (master)...                 refs/pull-requests/69/merge

如果我在此之后手动触发 Jenkins，它会构建最新的提交。

所以我的问题是，在我访问 BitBucket 中的实际 PR 页面之前，BitBucket 似乎并没有更新 refspec。我该如何解决这个问题？

谷歌搜索我最终找到了here 的问题，它的行为似乎是设计使然...

Answer 1

请参阅 Daves 的回答，了解为什么会出现这个“问题”以及为什么 Bitbucket 会以这种方式设计。

但是我能够通过更改 Jenkins 插件中的设置来解决我的特定问题，以“欺骗”Bitbucket 更新参考。

通过在 Jenkins 中将选项 Build only if Stash reports no conflicts 设置为 true（在 Build Trigger 下表示作业），您可以强制 Bitbucket 更新 refs，这意味着您将检查正确的提交

详情请见https://github.com/nemccarthy/stash-pullrequest-builder-plugin/issues/75

Answer 2

全面披露：我在 Atlassian 的高级支持团队工作。

首先，这不是一个错误 - 值得注意的是，拉取请求引用（在 refs/pull-requests/* 下）是 Bitbucket Server 的一个实现细节。它们不打算用于 CI，或通常依赖于开发。我们的一位开发人员的This comment 列出了在 CI 中构建这些引用可能不是一个好主意的一些原因。

为了让您了解更多技术背景，这些 ref 仅在查看拉取请求时创建 - 它们不是急切创建的。此外，/refs/pull-requests/* 下的 refs 可能随时更新 - 对源或目标分支的任何更改都将导致拉取请求被重新调整范围，但不保证此重新调整范围事件是即时的，并且可能与其他系统事件一起排队.这是我们不建议构建它们的主要原因之一。还有其他充分的理由不建立这些参考 - 考虑以下情况：

• Apple 的 Sarah 在 ios-core 中打开 PR #123，将 feature/hologram-ui-support 合并到 develop（我知道，我是个梦想家）
• refs/pull-requests/123 已创建，并为 feature/hologram-ui-support PR
运行 CI 构建
• 同时，Ahmed 将 bug/weird-apfs-edge-case 合并到开发中。这会导致 refs/pull-requests/123 重新调整范围，因为目标分支已更改，并且为 feature/hologram-ui-support PR
运行另一个 CI 构建
• Jane 将 feature/siri-asimov-laws-of-robotics-support 合并到 develop。 refs/pull-requests/123 再次调整范围，并为 feature/hologram-ui-support PR
运行另一个 CI 构建

您可以明白我的意思 - 因为这些 ref 会根据目标和源分支的更改重新调整范围，这导致 CI​​ 构建比您预期的要多得多。这对您的 CI 服务器来说可能非常繁重，因为实际上每个合并的 PR 都会触发每个打开的 PR 的构建。

一般来说，我会推荐以下两种方法之一：

1. 在您的 CI 构建中构建 merge：
   • 根据对源分支的更改触发构建，并让您的构建计划执行git checkout target; git merge source 之类的操作作为构建步骤。大多数 CI 系统应该原生支持这种工作流。
2. 如果您必须在 refs/pull-requests/ 上构建，请仅在 refs/pull-requests/<id>/merge-clean 上进行。这里还有其他合并类型本身就是失败的情况：merge-conflicted 和 merge-base，所以即使尝试构建它们也没有意义。

干杯，

戴夫