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

Question

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

在 BitBucket 中，我使用的是 Webhook to Jenkins for Stash，它会在每次拉取请求为 created/updated.

时通知我的 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 只能找到旧的。

当我运行 git ls-remote origin 提交并推送更新到现有 PR 后，我得到这个：

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

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

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

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

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

您可以明白我的意思 - 因为这些引用在目标和源分支的更改上重新确定了范围，所以它导致 CI 构建比您预期的要多得多。这可能会给您的 CI 服务器带来很大的负担，因为实际上每个合并的 PR 都会触发每个打开的 PR 的构建。

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

在您的 CI 构建中构建 merge：
- 触发器建立在对源分支的更改之上，并让您的构建计划执行类似 git checkout target; git merge source 的操作作为构建步骤。大多数 CI 系统本应支持这种工作流程。
如果您必须在 refs/pull-requests/ 上建造，请仅在 refs/pull-requests/<id>/merge-clean 上建造。这里还有其他合并类型本质上是失败案例：merge-conflicted 和 merge-base，因此即使尝试构建它们也没有意义。

干杯，

戴夫

Answer 2

查看 Daves 的回答，了解为什么会出现这种 "problem" 以及为什么 Bitbucket 是这样设计的。

但是我能够通过将 Jenkin-plugin 中的设置更改为 "trick" Bitbucket 来更新引用来解决我的特定问题。

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

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

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

BitBucket does not update refspec for PR, causing Jenkins to build old commits

git

continuous-integration

bitbucket

pull-request

jenkins