TeamCity可以将一个构建的输出提交到另一个svn存储库，从而启动另一个构建吗？

Question

到目前为止，我只使用TeamCity作为连续构建服务器。没有真正的整合。现在，我需要将一个共享项目的输出复制到另外两个依赖项目，然后依次启动它们的自动构建。也就是说，ProjectA和ProjectB都依赖于ProjectC。当在各自的存储库中发生任何提交时，所有这三个当前都由TC构建。我们希望将ProjectC的输出复制并提交给ProjectA和ProjectB。这样的提交将反过来启动两个依赖项目的构建过程。在谈论持续集成时，这似乎是一种常见的情况。不是吗？

为了澄清，我们使用TeamCity v.4.5.5（build 9103），SVN和nAnt作为我们的构建运行器。

编辑：当我说到有关提交到另一个存储库的内容时，我发生了错误。实际上，它们都位于同一个物理存储库中，只是位于层次结构中的不同级别。

Answer 1

我不知道TeamCity是否支持这一点，但这应该很容易自己编写脚本 - 作为构建ProjectC的最后一步添加一个脚本来检查ProjectC目录（不是整个存储库，只是一个保存的目录来自ProjectA和ProjectB的ProjectC的二进制文件，复制所有必需的文件并提交一些自动生成的消息 - 看起来很简单。

然而 - 这很危险。由于ProjectC的API发生了变化，或者某些未经测试的部分代码被破坏，ProjectA和ProjectB的构建可能会中断。这可能会破坏团队A和B的工作。我会寻求解决方案，每天/每周/任何其他时间段提交新版本的库。

此外，创建自动更改日志可能是个好主意 - 例如，如果您信任svn日志消息的质量，则可以从提交的发布中包含的所有“新”提交创建更改日志（或附加当前日志）消息，如果您决定在每次提交后选择推送新库）。这样，负责ProjectA和ProjectB的团队将能够轻松修复他们的构建，如果新库打破它 - 他们将确切知道更改的内容，而无需手动检查/询问团队C.

Answer 2

通常，您不会将构建输出提交到存储库。你确定那是你想要的吗？

您可以让TeamCity将输出（工件）从一个构建项目复制到另一个构建项目的目录中，但是为了提交它，您需要添加一些脚本，如批处理文件或类似文件。

Answer 3

在较新版本的TeamCity中，您可以定义工件依赖项，这将允许您根据示例创建“库”，并将该构建的工件拉入其他项目。如果您使用Node.js / npm之类的东西来构建项目，您也需要捕获输出文件夹（例如'dist'），这样当您恢复工件时，您可以解压缩单个文件夹而不是列表的依赖关系。

如果有人感兴趣，我可以扩展这个例子，只是想让人们通过谷歌发现这个现在更容易做到。