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

Question

我正在使用带有Git的本地BitBucket服务器。我正试图从连续集成开始，所以我已经设置了一个本地Jenkins实例。目标是让Jenkins签出拉请求并构建项目，然后向BitBucket报告结果。

在BitBucket中，我使用的是韦胡克去詹金斯藏东西，每次创建/更新拉请求时都会通知Jenkins实例。

在Jenkins中，当从上面的插件通知Jenkins时，我使用藏拉请求生成器插件让Jenkins签出拉请求。我使用了文档中的设置，即

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。

当我在对现有的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页面之后，参考文献似乎被更新了，我得到了以下结果：

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似乎并没有提高折射，直到我访问在BitBucket的急性公关页面。我怎么才能解决这个问题？

谷歌的问题，我结束了这里，似乎行为是故意的.

Answer 1

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

然而，我能够通过更改Jenkin插件中的设置来解决我的具体问题，以“欺骗”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

充分披露:我为亚特兰西安的总理支援小组工作。

首先，这不是一个bug -值得注意的是，拉请求参考(在refs/pull-requests/*下)是Bit斗Server的一个实现细节。它们不打算用于CI，或通常用于开发。我们的开发人员之一的这句话列出了为什么在CI中构建这些参考资料可能不是一个好主意的一些原因。

为了给您提供更多的技术背景，这些推荐只在查看拉请求时才创建--它们不是急切地创建的。此外，/refs/pull-requests/*下的引用可以随时更新--对源分支或目标分支的任何更改都将导致重新处理拉请求，但是不能保证该重处理事件是瞬时的，并且可以与其他系统事件一起排队。这是我们不建议建立在它们之上的主要原因之一。还有其他很好的理由不建立这些参考文献--考虑到以下情况：

• 苹果公司的莎拉在ios-core中打开PR #123，将整合为develop (我知道，我是个梦想家)。
• 为feature/hologram-ui-support PR创建refs/pull-requests/123，并运行CI构建。
• 同时，艾哈迈德将bug/weird-apfs-edge-case合并到开发中。这会导致重新处理feature/hologram-ui-support的refs/pull-requests/123，因为目标分支已经更改，并且另一个CI构建也会为该PR运行。
• Jane将feature/siri-asimov-laws-of-robotics-support合并为develop。feature/hologram-ui-support PR再次重新处理refs/pull-requests/123，并运行另一个CI构建。

您可以理解我的意思--因为这些裁判在对目标和源分支的更改中被重新处理，因此会产生比您预期的更多的CI构建。这可能会对您的CI服务器造成很大的负担，因为实际上，每个合并的PR都会触发每个开放PR的构建。

一般来说，我推荐两种方法中的一种：

1. 在CI构建中构建合并：
   • 根据对源分支的更改触发构建，并让您的构建计划执行类似于git checkout target; git merge source的构建步骤。大多数CI系统都应该有对这种工作流的本地支持。

​

1. 如果您必须构建refs/pull-requests/，那么只在refs/pull-requests/<id>/merge-clean上这样做。这里还有其他合并类型，它们都是固有的失败案例：merge-conflicted和merge-base，所以即使尝试构建这些合并类型也没有意义。

干杯,

戴夫