gpt4 book ai didi

TeamCity 拉取请求触发的合并构建

转载 作者:行者123 更新时间:2023-12-02 01:48:38 24 4
gpt4 key购买 nike

我一直在尝试配置我们的 TC 安装以处理以下场景:

我们有多个开发人员并行处理多个错误。我们的源代码存储在 github 中,我们正在使用拉取请求。我希望 Teamcity 触发构建拉取请求,如下所述:http://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/这似乎很容易做到。不幸的是,看起来这样的配置不会合并拉取请求,而只是从存储库中拉取它。

让我给你举个例子:

开发人员 A 打开 pull request nr 1(基于代码版本 0010)。开发人员 B 也基于代码版本 0010 打开一个 pull request nr 2。存储库中的当前代码版本是 0015。我们每个 pull request 的 TeamCity 服务器应该首先 check out 源代码的版本 0015,然后合并 pull nr 1 中的更改。如果合并成功,那么它应该尝试编译代码。应该对 pull nr 2 进行类似的操作。

请注意,我需要 TC 来合并分支中代码的当前版本,而不仅仅是从拉取请求中拉取版本。

拉取请求 nr 1 被审查和接受,并合并到生产存储库中。这应该会触发 pull request nr 2 的重建,因为现在当前分支不是 0015,而是带有 pull nr 1 中的代码的 0015。

我知道对于许多拉取请求,每次合并都会触发大量的构建/重建。但这正是我需要 TC 的原因。持续集成过程的一部分应该是确保来自拉取请求的源代码应该与当前的 head 合并而没有任何冲突。

按照链接中的描述配置 TC 服务器后,它并没有真正与 HEAD 合并,而只是执行 git pull 和编译。这根本没有帮助,因为这应该始终有效(前提是开发人员在提交更改之前在他们的机器上编译代码)。

我很感激关于如何设置我们的 CI 环境的任何提示或想法,因为我们可以针对最新的代码测试实际合并,而不仅仅是简单的编译。

最佳答案

TeamCity 可以做到这一点。方向在您指向的链接中:( https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/)

简而言之,使用 +:refs/pull/*/merge作为让 TeamCity 使用合并的 PR 分支的分支规范。使用 +:refs/pull/*/head只需按照您的描述构建未合并的分支。

关于TeamCity 拉取请求触发的合并构建,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24091955/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com