Keeping history when converting to portable Kotlin DSL
We currently configure our build configurations from UI without using versioned settings. Over the time configuration has gotten more messy with small changes here and there. Now we're going to configure the build steps into Kotlin DSL and clean the dirt at the same time. One problem however, is about how to preserve history for builds. Because of all the changes during the history, the build configuration and project IDs might be a bit of anything and with portable Kotlin those are very well defined. If we just apply Kotlin DSL, the old jobs will need to be achieved or removed but we'd like to keep history in new Kotlin based build configurations. So my question is, how to best achieve this? How can we re-create jobs in portable Kotlin DSL and migrate history from old jobs to new ones? Is it enough to change IDs of old jobs to what they will be with Kotlin DSL before deleting them and then re-create them with Kotlin? Or how should this be done?
Please sign in to leave a comment.
Hi,
Converting to the Kotlin DSL shouldn't imply losing the history. First of all, if you export the project to the Kotlin DSL, the items will be generated for you. Simply modifying their properties should work.
Then, the projects are identified through an internal ID. As long as you keep the ID stable, all the builds should be traceable to the build, even if you change its configuration.
Thanks for answer. Yes, I know that just converting to Kotlin does not lose history. However, our current setup without Kotlin is a mess, with random IDs and somewhat poor build configuration names. While converting the projects to Kotlin DSL, we'd like to use the portable DSL and clean things up. Thus, the IDs will not stay stable during the conversion but instead most of the jobs will change their ID. I noticed there is a way to attach history from removed build to existing one which I guess does what I want. A bit cumbersome with tens of build configurations but will do unless some better way is there.
The ID you see (for example MyProject_MyBuildConfig) is not the same ID as the one I mentioned. When exporting, you will get a UUID (a random string of characters), which is what teamcity uses internally. To attach the history of a removed build to an existing one you basically modify this UUID, so simply... don't modify it from the original, and that should do.