4

We're using TeamCity's build feature File Content Replacer to replace the build version number in multiple AssemblyVersion.cs files, following TeamCity's documentation on Changing only the last version part / build number of the AssemblyVersion attribute:.

Our file list look like this:

CommonAssemblyInfo.cs
**\Properties\AssemblyInfo.cs

It works, but it sometimes takes up to 10 minutes before it even starts. This usually happens when the build haven't run for 24 hours or more, but sometimes on subsequently builds also.

build log

Any ideas why this happens? We also have multiple projects with the exact same setup, where this never happens.

jonespen
  • 96
  • 9
  • This may be caused by either the directory tree being too deep, or the list of files matching path pattern being too long, or by charset auto-detection taking too long to complete. Does anything change if you explicitly set the **File encoding** (under *File Content Replacer* settings) to `UTF-8`? – Bass Aug 01 '16 at 08:38

1 Answers1

3

Figured it out, it hit the dreaded node_modules folder with 40k+ files. Justified the file list pattern to exclude the folder, and now it finishes in 5 seconds.

For future ref, here is our Process files list

CommonAssemblyInfo.cs
+:**/Properties/AssemblyInfo.cs
-:**/node_modules
jonespen
  • 96
  • 9