tfs - TeamCity CI 为 TFS 功能分支构建

标签 tfs continuous-integration teamcity teamcity-7.0

除了不断构建发布/功能分支之外,我几乎在 Team City 中完美设置了所有内容。

这将很难描述,但希望它应该是有道理的。

我在 TFS 中有以下源代码管理布局:

$/ProjectName/releases/1.2
$/ProjectName/features/create-doodads
$/ProjectName/trunk

我有以下构建参数:
env.SourceBranch = trunk

这用于配置源代码控制根:
Root = $/ProjectName
CheckoutRule = +:%env.SourceBranch%=>./

这就是事情变得有趣的地方:

当我运行 定制版本 并手动指定 env.SourceBranch那么构建将使用指定的分支运行,因为它是在 Checkout Rule 中配置的。 7.1 有一个新功能,它在项目页面上的构建号旁边显示一个分支标签,然后这将正确显示在构建和构建链中的所有后续构建旁边。

到目前为止一切顺利,但是,当我再次 checkin 分支时,它不会自动运行。

我明白为什么会发生这种情况...结帐规则默认为 trunk这意味着它与 releases 下发生的任何 checkin 都不匹配或 features ,但是我不确定我的选择是什么。

我想我想要的是能够指定一个构建触发器,该触发器设置一个传递给 vcs 根的参数......或类似的东西。

任何帮助将不胜感激,如果这不清楚,请告诉我,我会尝试进一步解释。

编辑:

我尝试使用结账规则,做这样的事情:
+:trunk=>./
+:releases/*=>./
+:features/*=>./

不幸的是,这不起作用。

看来我正在尝试做的是suggested here ,这让我觉得这是不可能的。

最佳答案

我认为您所描述的只是尝试根据触发器从不同的分支自动构建(类似于 git 的工作方式)。不幸的是,截至撰写本文时,这不是我所知道的 TC 中分布式模型(如 git 和 mercurial)之外的源代码控制选项。

我建议基于模板创建不同的构建配置,每个配置使用构建参数中指定的不同分支。我认为如果您遵循 CI 推广模型,这将是最有帮助且易于追踪的。因此,您的示例中有三个构建配置,并且有一个模板,其中除了一个参数:%env.SourceBranch% 之外,所有三个构建之间的所有内容都完全相同。

关于tfs - TeamCity CI 为 TFS 功能分支构建,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12376737/

相关文章:

git - 将默认的 Git merge 放入 TFS

java - 由于 SVNAuthenticationException,Hudson 构建失败

Github Action 中的 Git 历史

c++ - 为 DLL 库配置 Google 测试项目

node.js - 如何解决在 TeamCity 中创建 FileSet 时出现的 NAnt 错误?

azure - 是否可以在不使用 Visual Studio 的情况下从 TFS Azure 下载源树?

tfs - 默认和托管代理队列之间的区别?

tfs - 如何在同一测试运行中重新运行失败的测试用例(测试运行由 TFS2015 vNext Run 功能测试任务启动)

Azure网站持续部署总是选择错误的项目

github - 使用 TeamCity 和 Github 构建对特定分支的拉取请求