Question

我们的构建管道设置为 Team City （版本2017.1.5），我们使用内部 Bitbucket 服务器（版本4.8）作为我们的git存储库。我们的分支模型是GitHub Flow

我们使用mendhak Team City插件向Bitbucket服务器报告构建状态。此外，我们已在团队城市中创建了一个内置版本，以使用分支触发器构建拉取请求：+:refs/(pull-requests/*)/merge。

但是，此分支过滤器的构建状态在拉出请求窗口/页面的Bitbucket中不可见。

如果我们在特征分支上使用分支过滤器（例如+:refs/heads/(feature/*)），则在PR上正确显示构建状态。但是，我们有兴趣在我们的Pull请求中显示PR构建状态。

我们发现，自2013年以来，Atlassian已经有open issue（是 - 差不多5年）。看起来它不会很快修复。

问：

是否有可用的解决此问题的变通办法或Bitbucket插件（或Team City插件）。我们希望避免添加任何额外的分支过滤器/触发器。

我觉得这是一个相当普遍的问题，应该已经被许多其他团队/个人解决了。我恰好没有找到合适的资源/材料。

任何指示，都非常感谢。

Answer 1

问题在于您使用的引用（在refs/pull-request/*下）仅在内部，并且在Bitbucket Web UI中不可见。

想象一下你在Bitbucket Server上有一个像这样的回购：

现在假设您从＆＃34;分支＆＃34;创建PR到＆＃34;掌握＆＃34;。 Bitbucket Web UI中显示的引用不会改变，但是git clone --mirror会显示在幕后创建的隐藏refs/pull-request/*引用：

git clone --mirror http://vm.bit-booster.com/bitbucket/scm/bb/rebase-example-1.git
cd ./rebase-example-1.git
git log --all --date-order --decorate --graph

结果：

与仅refs/pull-requests/1/merge相比，拥有Team City或Jenkins或Bamboo或使用01ebefda503c的任何构建（例如，此示例中为branch）确实具有一个主要优势。在实际合并之前，您可以预先构建真实的东西（合并）。这就像是对未来的预示。

但如果您尝试使用相同的ref发布build-status，那么它有一个主要的缺点。在Bitbucket的Web UI中看不到提交ID 01ebefda503c，因此拉取请求构建状态集成不会成功（或失败）构建。

但这是一个非常好的解决方法。让Team City（或Jenkins或Bamboo等）毫无意义地将构建状态推送到抢先合并，然后使用curl将相同构建状态的副本发送到HEAD ^ 2，即01ebefda503c^2又名e466842138b65。

（背景：插入符号操作符＆＃39; ^＆＃39;抓取指定提交的给定父级，例如，^ 1是第一个父级，^ 2是第二个父级，如果您正在使用疯狂的人，^ 3将是章鱼合并中的第三个父母，依此类推。就个人而言，我几年没见过真正的章鱼合并。还记得绝大多数提交只有一个父母，又名＆＃34 ; string-of-pearls＆＃34;样式提交。只有合并有2个或更多父母。）

你可以像这样对HEAD ^ 2发起构建状态：

curl --user user:password -H "Content-Type: application/json" -X POST -d \
  '{"state":"SUCCESSFUL", "key":"K", "name":"K-9", "url":"http://bit-booster.com/"}' \
  http://vm.bit-booster.com/bitbucket/rest/build-status/1.0/commits/e466842138b658a1b09caa0b1caea065194311ce

然后在PR上可以看到build-status。

结帐我的Bitbucket add-on。： - ）

在Bitbucket中显示PR Build状态

1 个答案: