首页 文章

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

提问于
浏览 次
1

我正在使用Git的本地BitBucket服务器 . 我正在尝试开始使用Continous Integration，因此我已经设置了一个本地Jenkins实例 . 目标是让Jenkins检查pull-requests并构建项目，然后向结果报告BitBucket .

在BitBucket中，我使用的是Webhook to Jenkins for Stash，每当创建/更新一个pull-request时，它就会通知我的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似乎行为是设计的......

git jenkins continuous-integration bitbucket pull-request

2 回答

  • 0

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

    然而，我能够通过更改Jenkin插件中的设置来解决我的具体问题，以“欺骗”Bitbucket更新refs .

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

    有关详细信息，请参阅https://github.com/nemccarthy/stash-pullrequest-builder-plugin/issues/75

    回复于
  • 2

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

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

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

    • Apple的Sarah在 ios-core 打开PR＃123，将 feature/hologram-ui-support 合并到 develop （我知道，我是一个梦想家）
      创建

    • refs/pull-requests/123 ，并为 feature/hologram-ui-support PR运行CI构建

    • 与此同时，艾哈迈德合并 bug/weird-apfs-edge-case 进入开发 . 这导致 refs/pull-requests/123 被重新调整，因为目标分支已更改，并且另一个CI构建针对 feature/hologram-ui-support PR运行

    • Jane将 feature/siri-asimov-laws-of-robotics-support 合并为 develop . refs/pull-requests/123 再次重新调整，并为 feature/hologram-ui-support PR运行另一个CI构建

    您可以看到我的意思 - 因为这些引用会在目标和源分支的更改中得到重新调整，因此会产生比您预期的更多的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 ，所以即使尝试构建它们也没有意义 .

    干杯，

    戴夫

    回复于

相关问题