我们正在使用 TeamCity 的构建功能文件内容替换器来替换多个 AssemblyVersion.cs 文件中的构建版本号,遵循 TeamCity 关于 Changing only the last version part / build number of the AssemblyVersion attribute: 的文档。 .
我们的文件列表如下所示:
CommonAssemblyInfo.cs
**\Properties\AssemblyInfo.cs
它有效,但有时甚至需要长达 10 分钟才能开始。这通常发生在构建没有运行 24 小时或更长时间时,但有时也会发生在随后的构建中。
任何想法为什么会发生这种情况?我们还有多个具有完全相同设置的项目,但这种情况从未发生过。
最佳答案
想通了,它击中了可怕的node_modules
包含 40k+ 文件的文件夹。对齐文件列表模式以排除文件夹,现在它在 5 秒内完成。
对于 future 的引用,这里是我们的流程文件列表
CommonAssemblyInfo.cs
+:**/Properties/AssemblyInfo.cs
-:**/node_modules
关于teamcity - TeamCity 中的慢 "File Content Replacer",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38656705/