Moving many projects to a new agent machine - Update build settings editing XML files under <teamcitydata>\config\projects
Hi,
we are currently setting up a new agent virtual machine and plan to move all 100+ builds from the old machine to the new one.
The required build tools - several different ones and versions - have been installed and some project builds have already been tested successfully on the new machine.
Most projects need an update in their configuration because we changed some directories of the required tools installed on the new machine. I have found out that I can edit the .xml file under “<teamcitydata>\config\projects\…\buildTypes” and the change gets visible in the TeamCity Web UI when that gets refreshed. I wondered if it would be safe to go this way to achieve these mass changes, searched the web for it and found this old thread:
What is the safe way to modify the project.xml files? – TeamCity Support | JetBrains
There it is stated that it should be safe if no concurrent editing happens. We are a quite small team, so I can make sure, nobody edits while the files get updated.
Can you confirm that it is still safe (under that condition) with the current TeamCity version?
It would save a lot of effort if I could go that way. Backing up the files before the change, of course.
Kind regards,
Ralph
Please sign in to leave a comment.
Hi,
In the TeamCity, it is still safe to directly edit the XML files under <TeamCityDataDirectory>/config/projects/.../buildTypes, provided that:
1. No concurrent editing happens (neither through the Web UI nor other scripts while you’re modifying the files).
2. You back up the files first, as you already plan to.
3. After changes, TeamCity detects and reloads the updated configs automatically. If you see your changes reflected in the Web UI after a refresh, then TeamCity has picked them up correctly.
4. If any syntax error or inconsistency is introduced, TeamCity will log it (teamcity-server.log) and usually mark the project/build configuration as invalid in the UI rather than crashing.
That said, generally recommends using the following safer approaches if possible:
Versioned Settings (Kotlin DSL) → You’d have all the configurations in source control, and mass changes (like paths to tools) could be scripted and applied more transparently.
Best Regards,
Tom
Hi Tom,
thanks for your response.
Kind regards,
Ralph