What is the safe way to modify the project.xml files?
Followed by one person
I attempted to modify a project.xml file while the TC master was running, and it resulted in all changes made via the web UI to the same project to be lost. Specifically, all the dependency information was gone. I'm wondering if there is a need to acquire a lock to modify those files.
This is in order to programmatically generate build configs, until there is a way to do it via a web API.....
Please sign in to leave a comment.
Christian,
In addition to my answer in the issue
If the dependencies were lost this is probbaly a bug.
What TeamCity verison was it on?
Can you reproduce this?
We are running TeamCity Enterprise Version 5.1.5 (build 13602)
I haven't tried it again since that happened. If I understood how your implementation of "live files" work, maybe I can work up more confidence.
Attempts to repro it in our staging environment of course failed.
Christian ,
Changing the XML configuration files should not require any locks. It should be just like performing the same chnage from web UI.
You might have experienced the bug.
Upgrade is recommended to the most current TeamCIty version (6.0.3 as of now with 6.5 to be released really soon).
It does kind of feel like magic. How do you do it? How do you ensure that the ids remain unique?How do you serialize the changes to that file with changes coming from the web UI?
Are you really saying that I can make whatever modifications I want to any xml files and it will Just Work (tm) ?
Christian,
Of course there are certain limitations. Basic idea is: if you do something form the web and it changes the XMLs on disk , you can do the same type of change to XML on disk and it will be understood by the server.
If you add a new entity, you need to ensure ids does not clash with existing ones. If you need to reference an entiry, you need to provide the correct id.
I guess you can get the idea e.g. by reading through the comment.
It still doesn't give me the warm fuzzies...
My goal is to write a script that will insert complex build configs into the system - so I will be creating new ids for those configs. How can I avoid clashing with an id created by a user choosing to use the web UI?
Is the "bt" in "bt123" something that is required, or can I use a different prefix to avoid clashes?
And generally, what happens when I save the new version of the file at the same time your web app tries to write it? who wins, how to you merge - assuming you do merge...?
I would feel much more comfy if there was a way to get a lock.
I'm sorry to be a pest about this, but finding a good and reliable solution to automatically create build configs is crucial for us. The current process is putting a severe dent on internal adoption of TeamCity.
Sorry for delay. TeamCity watches for changes in project-config.xml files and reloads these files if changes occur. Of course the whole operation is not atomic, so if you create a lot of interdependent projects, some problems may arise, TeamCity may not detect all of the changed files and may try to load only one of them, but since it depends on others loading fails.
But if projects are independent you can safely modify project-config.xml files. When TeamCity detects change in a file, it tries to load new configuration. If loading fails for some reason, TeamCity should leave current project and ignore external change. If loading succeeds, TeamCity substitutes projects in memory model.
For now, there is no way to ask TeamCity explicitly to reload its' config files.