Continuous integration TeamCity能否将一个构建的输出提交给另一个svn存储库，从而启动另一个构建？

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

为了澄清，我们使用TeamCity v.4.5.5（构建9103）、SVN和nAnt作为构建运行程序

---

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

通常您不会将生成输出提交到存储库。你确定这就是你想要的吗

---

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

我不知道TeamCity是否支持此功能，但这应该很容易自己编写脚本-作为内置ProjectC的最后一步，添加一个脚本，从ProjectA和ProjectB中签出ProjectC目录（不是整个存储库，只是一个保存ProjectC二进制文件的目录），复制所有必需的文件并提交一些自动生成的消息-看起来相当简单

然而，这是危险的。ProjectA和ProjectB的构建可能会中断，因为ProjectC的API已更改，或者某些未经测试的代码部分已中断。这可能会打乱团队A和B的工作。我会选择每天/每周/任何其他时间段提交一次新版本库的解决方案

---

另外，创建一个自动化的变更日志可能是一个好主意——例如，如果您信任svn日志消息的质量，您可以从提交的发行版中包含的所有“新”提交创建一个变更日志（或者附加当前日志消息，如果您决定在每次提交后推送新库）。这样，负责ProjectA和ProjectB的团队将能够在新库破坏时轻松修复其构建-他们将准确地知道更改了什么，而无需手动检查/询问团队C。

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

---

如果有人对此感兴趣，我可以对这个例子进行扩展，只是想让人们通过谷歌找到这个，现在做起来容易多了。

在这个场景中，ProjectC成为ProjectA和ProjectB的第三方。因此，它的输出应该与其他第三方程序集一起存在于两个项目的“lib”文件夹中。所以，是的，提交输出肯定是我想要的。使用像ProjectA、ProjectB和ProjectC这样的名称会使示例变得模糊，但从本质上讲，这些项目中的每一个都是由业务的不同部分所拥有的，并且不被彼此编辑。因此，在这种情况下，希望ProjectC以汇编格式提供给消费者。非常好的提示。看起来TeamCity并没有直接做到这一点，所以我现在正在编写脚本。您还让我停下来思考是否希望在每次提交ProjectC后都发生这种情况。我想大概在夜间建造就足够了。自动变更日志的想法也是一个有趣的想法。我从没想过要这么做。不过，我不确定我是否足够信任日志消息。最好让其他项目的构建脚本从原始构建中提取二进制文件。这给了您更多的灵活性，并且意味着您不太可能无意中破坏这些项目。