Question

我正在使用Git的本地BitBucket服务器。我正在尝试开始使用Continous Integration，因此我已经设置了一个本地Jenkins实例。目标是让Jenkins检查pull-requests并构建项目，然后向结果报告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会以这种方式设计。

然而，我能够通过更改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

完全披露：我为Atlassian的Premier Support团队工作。

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

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

Apple的Sarah在 ios-core 中打开PR＃123，将 feature / hologram-ui-support 合并到 develop （我知道），我是梦想家。
refs/pull-requests/123已创建，CI构建针对功能/全息图-ui-support PR
与此同时，Ahmed合并 bug / weird-apfs-edge-case 进行开发。这导致refs/pull-requests/123被重新调整，因为目标分支已更改，并且另一个CI构建针对 feature / hologram-ui-support PR
Jane将 feature / siri-asimov-law-of-robotics-support 合并到 develop 中。 refs/pull-requests/123再次重新调整，另一个CI版本针对功能/全息图-ui-support PR

您可以看到我的意思 - 因为这些引用会在目标和源分支的更改中得到重新调整，因此会产生比您预期的更多的CI构建。对于您的CI服务器而言，这可能会非常繁重，因为每个合并的PR都会触发每个开放PR的构建。

一般来说，我建议采用以下两种方法之一：

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

干杯，

戴夫

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

2 个答案: