具有多个 VCS 根的 TeamCity/Bitbucket 服务器拉取请求

TeamCity / Bitbucket Server pull request with multiple VCS roots

我正在使用 TeamCity Enterprise 2021.2(内部版本 99542)和 Bitbucket Server v7.14.0。我在 Teamcity 中有一个构建配置,其中包含 3 个 VCS 根:Repo1、Repo2 和 Repo3。每个回购协议都有一个“主”分支,这是所有 3 个回购协议的默认分支。 Repo 1 和 2 有一个名为“feature1”的分支。

如果我将所有 3 个存储库中的分支规范设置为 refs/heads/* 并将 VCS 触发器设置为 Repo1,并将过滤器设置为 +:*,则可以实现所需的行为。当对 Repo1 中的 feature1 进行更改时会触发构建,构建会在 both Repo1 和 Repo2 上检出 feature1,而在 repo3.

上检出 main

问题是我只想在 Repo1 中创建或更新拉取请求时触发构建。因此,我使用拉取请求构建功能触发 Repo1 中的任何拉取请求,并将 Repo1 中的分支规范设置为 refs/heads/main(因此不会触发重复构建)这导致 几乎 期望的行为。

我在 bitbucket 的 Repo1 中为功能 1 创建了一个 PR。并触发构建。问题是 feature1 只在 Repo1 而不是 Repo2 中签出。有什么方法可以为 Repo2 配置 VCS 根目录,以在 PR 触发构建到 Repo1 时检查 Repo1 上使用的同一分支?

我怀疑问题与某些 TeamCity 构建配置变量有关。在具有预期行为的第一种情况下,teamcity.build.branch 设置为 refs/heads/feature1。耶。在第二种情况下,teamcity.build.branch 设置为 pull-requests/## 而 teamcity.pullRequest.source.branch 设置为 feature1.

甚至不是变量的问题,而是构建(逻辑)分支的问题

如果您正在使用 Pull Requests 构建功能,它(内部)会在您的构建配置上下文中扩展 VCS 根的分支规范,其模式包括 refs/pull-requests/123/from 种由 Bitbucket Server 提供的分支拉取请求。 因此构建的逻辑分支名称变为 pull-requests/123,而不是拉取请求的源分支。由于其他存储库中没有这样的拉取请求,因此为它们选择了默认的 VCS 分支。这在大多数情况下是可以的,因为任何 VCS 托管都不支持诸如 multi-repo 拉取请求之类的事情。至少在我看来不是。在我们看来,在大多数情况下,以下改进可能对许多用户有用:回退到与拉取请求的目标分支相匹配的 VCS 分支,而不是 VCS 根的默认分支。如果出现此类功能请求,将对此进行讨论。

无论如何,您的情况有所不同,您似乎想在所有三个存储库中使用源代码分支。如果满足以下功能要求,它可能会满足您的需求:https://youtrack.jetbrains.com/issue/TW-70491 我们目前正在研究它,它可能很快会作为一项实验性功能出现在我们的一个错误修复版本中,并作为今年下一个功能版本中的适当功能。请关注该问题以保持更新。

干杯, 安东