TeamCity 在多 VCS 设置中构建单独的拉取请求

Question

我正在尝试为更大的项目设置 TeamCity 10。我们有 3 个不同的 GitHub 存储库，它们都是构建所必需的。它们不能像今天的设置那样单独构建。如果我使用所有 GitHub 存储库设置项目，我可以将它们全部放在一个文件夹中，从而成功构建所有内容。

结构基本上是这样的：

• 基础仓库
• 用户界面回购
• 插件回购

所有签出到同一个文件夹并开始构建。

我现在的问题是我需要在每个 repo 的特定拉取请求上运行构建。我需要一种手动或自动启动构建的方法，例如插件 repo 上的 PR 1234，然后在其余部分使用 master。

我已经尝试了几种设置，但我无法让它按我想要的方式工作。最好的情况是手动构建启动弹出窗口将为每个存储库提供“分支”下拉菜单，但它总是只有那个。

我考虑过使用快照依赖项，但似乎需要单独构建它们中的每一个，而目前无法完成。我希望它们被单独“拉动”并作为一个项目构建。

感谢您对此问题的任何帮助，如果有不清楚的地方，请随时提出问题。

谢谢！

Answer 1

为此我所做的是创建多个 VCS 配置和 3 个独立的项目。

1. 基础仓库：默认分支：master
2. Base Repo：默认分支：master + 分支规范+:/refs/pull/*/merge
3. UI Repo：默认分支：master
4. UI Repo：默认分支：master + 分支规范+:/refs/pull/*/merge
5. 插件仓库：默认分支：master
6. 插件仓库：默认分支：master + 分支规范+:/refs/pull/*/merge

基础回购拉取请求：

我们将构建 Base Repo 的 Pull Request (2)

这个项目将使用master 版本的 UI Repo 构建拉取请求。 (3)

此项目将使用 master 版本的插件仓库构建拉取请求。 (5)

UI 回购拉取请求：

我们将构建 UI Repo (4) 的拉取请求

该项目将使用master 版本的基础回购构建拉取请求。 (1)

该项目将使用master 版本的插件仓库构建拉取请求。 (5)

插件拉取请求：

我们将构建插件仓库的拉取请求（6）

这个项目将使用master 版本的基础仓库构建拉取请求。 (1)

此项目将使用master 版本上的 UI 测试构建拉取请求。 (3)

编辑：

如何处理拉取请求

从评论中，我完成了这个答案。 我创建了一个watcher，以便自动启动拉取请求的构建。 watcher 是一个 TeamCity 构建，它使用 schedule trigger 功能定期运行。

这是该功能的伪代码

parameters:
   - ValidatorName

Load Octokit
// Filter is on every Open Pull Request
openPR = Octokit.PullRequest.GetAllForRepository(filter);      

foreach(pr in openPR) {

    // Define if the PR should be queued.
    // Check if the PR is not already queued.
    queuedBuilds = Execute-HttpGetCommand ("http://<teamcityServerUrl>/httpAuth/app/rest/buildQueue?locator=buildType:validatorName");
    foreach(queued in queuedBuilds) {
        if(queued.branchName = pr.Number) {
               # Flag to not queue the build.
               shouldQueue = false;
        }
    }   

    if(shouldQueue) {
        Execute-HttpPostCommand(
            "http://<teamcityServerUrl>/httpAuth/app/rest/buildQueue", 
            "<build branchName=""pr.Number""><buildType id=""validatorName""/><comment><text>Automatic launcher of Pull Request</text></comment></build>");
    }
}

validator 的概念出现了，它是一个特殊的构建，具有我们想要在拉取请求上测试的快照依赖项。 此构建将加载 octokit 并使用 Octokit.MergePullRequest 对象。

Answer 2

如果它们不能单独构建，那么它们不应该在单独的存储库中。

如果它们都在同一个 repo 中，它将为您节省很多问题，然后您可以通过 pull-request 和功能分支控制何时构建。