kotlin dsl: Refactor-rename BuildTypes but retain build history
I found out the hard way after cleaning up all the inconsistent naming our our build types, that after renaming I lost all the build history. This is because the kotlin generator did not include the BuildType.id, but the value (based on the class name?) is in the table build_type_mappings.
Now I'm trying to go back and set the id values based on what it says in the table. Unfortunately the table has multiple version of mappings for the same BuildType, as I have renamed several times while getting to a good a convention.
How do other deal with this? Do you just never refactor your BuildTypes? Or use a uuid generator? Or ...?
Please sign in to leave a comment.
it also seems that the table includes older build ids even from when the UI was in control of the ids. There is/was the control to regenerate the id in the UI, with some message that dependencies may be affected:
This ID is used in URLs, REST API, HTTP requests to the server, and configuration settings in the TeamCity Data Directory.
Was it that every time we regenerated the id via the ui the build history was lost but we just did not notice? Or did the table get updated by the ui?
Hi Barry,
I'll try to address some of your concerns here. TeamCity holds the build history through the internal IDs, not the external ones. For user-facing features where an ID is required (URLs, REST API, etc), an external ID is defined (typically of the form <projectname>_<buildconfigname>, which is kept internally tied to the UUID. If you modify the external ID in the UI, teamcity knows that it's the same build configuration (because you are in the build config page) and can update the reference from the UUID to the external ID. This is much more complex in the DSL, because externally modifying the external ID cannot be differentiated from simply creating and removing a build configuration. It's not that teamcity cannot "decide" that it's a replacement, it's that in a number of instances it will not be, leading to much harder to solve problems.
When generating the DSL, if you select NOT to get it as portable DSL, TeamCity will add the UUIDs to the definitions in the DSL. As you have been experiencing, if you add explicitly the UUIDs to the configurations, the build history will be restored just fine because of this association
So, with this in mind, if you refactor the IDs in the DSL, yes, teamcity will initially lose track of the build history. You can recover it by simply resetting the IDs to their previous values, and to prevent the values from getting disjointed from the start, you can download the dsl in non-portable format.
I hope this brings some light onto the issue.