在TeamCity中的快照依赖项中覆盖参数

TS.*_*TS. 6 teamcity

我真的无法理解teamcity(7.1)中快照依赖的概念.

我们有一个构建项目,它根据构建参数(数据库名称和文件)部署数据库,我有一个构建项目,用于构建和部署我们的Web应用程序.

我现在要做的是链接这两个构建但覆盖构建参数.我发现手册如何访问依赖性构建参数(%dep.btXX.yyy%),但我不想访问它们,我想覆盖它们!

我怎样才能做到这一点?我已经创建了一个新的构建,其中我触发构建和部署,然后是数据库构建,但它完全忽略了我的依赖项参数,而且我也无法更改构建的顺序.

感谢帮助!

ocr*_*tte 8

根据文档,现在可以在Teamcity 9中使用:

覆盖依赖项属性

从TeamCity 9.0开始,可以通过在依赖构建中重新定义它们来覆盖依赖项参数.例如,构建配置A取决于B,B取决于C; A能够使用以下格式更改其任何依赖项中的参数:reverse.dep ..

也可以一次更改所有依赖项中的参数:reverse.dep.*.

可以在自定义构建对话框中或通过构建配置参数在依赖构建A的参数名称中指定要覆盖的依赖项属性.

将新参数推送到构建中将取代"如果存在合适的"快照依赖性选项,则不要运行新构建,并且如果参数设置为非默认值,则可以触发新构建.

  • 您能提供一个使用示例吗? (2认同)

Jac*_*eja 0

更新:此答案仅与 TeamCity v8 或更早版本相关

我自己尝试过,但遗憾的是我怀疑目前不可能。

构建依赖项设置文档支持这一点:

当构建 A 依赖于构建 B 时,您可以将属性从构建 B 传递到构建 A,即属性只能在构建链流的方向上传递,反之亦然

我认为这样的(通常合理的)原因是由于以下原因:

  • 相关构建配置可能是多个其他构建配置的依赖项。

想想看:如果两个父母想要将他们的(不同的)参数传递给依赖构建,他们会从“最后一次成功的构建”中得到什么?理论上,TeamCity 可以检查上次构建的属性是否与所需的匹配(否则重建)。但即便如此,您最终也会得到所有不同环境的丑陋的构建历史。这确实不符合构建配置的概念。

重用构建配置的最佳方法是将它们模板化,然后创建多个项目,在项目级别设置属性,以便它们可用于所有包含的构建配置。

最终,最好的建议可能是重新考虑您是否确实需要为项目使用两种构建配置。最佳实践是最大限度地减少构建配置和构建步骤的数量 - 将尽可能多的构建逻辑放入您自己的脚本中。