In fact, this feature existed since TeamCity 1.0, though it isn’t much publicized.
Yes, we admit that we are lazy developers, and we don’t like to restart the programs after editing their configuration files. That’s why IntelliJ IDEA monitors the changes on the disk and reloads files automatically after an external change takes place. And the same is true about TeamCity: it monitors the state of the configuration files and picks up the changes if the files were modified.
FYI: TeamCity server uses XML-based configuration files to store information about system-wide settings, such as authentication scheme, version control roots, third-party reports configuration, etc. The information about configured projects and various build settings is also stored in XML files.
To be more specific:
- After any changes in TeamCity server configuration files, such as main-config.xml, project-config.xml or any *-config.xml, TeamCity reloads the server configuration (it monitors file modification timestamp). The important consequence – when you save these files, they should be in the valid and parseable state. If you are brave enough to manually edit these files, be careful not to break them.
- If you modify the build agent’s buildAgent.properties file, there is no need to restart the build agent. The build agent will wait until currently running build finishes and will restart and reload its configuration automatically.
This is not a killer feature, of course, but it is interesting enough to deserve a separate blog post.