The mix of top-level and project-level settings scripts is not supported
I am migrating a large project to Kotlin. Our current project hierarchy is something like this, where one sub project has been migrated and the rest remain managed by the gui:
RootProject/Kotlin_SubProject
RootProject/NonKotlin_SubProject1
....
RootProject/NonKotlin_SubProjectN
Right now "Kotlin_SubProject" has its own settings.kts file. I would like to make a settings.kts file for each project, similar to how the generated dsl looks. I created files similar to the generated DSL that generate the XML I would expect and have no problem building the project in my IDE. When I push to TeamCity however, I received the following error:
The mix of top-level and project-level settings scripts is not supported. To proceed, remove the project-level scripts: .teamcity/Kotlin_SubProject1/settings.kts, .teamcity/Kotlin_SubProject2/settings.kts
I have no other settings.kts files, so I do not understand what the top-level project is or how to remove it.
Alternatively, is there a better way to have multiple Kotlin projects as subprojects of a gui project? Making my new projects subprojects of the existing Kotlin managed project is not an option.
Please sign in to leave a comment.
Hi Ian,
If the parent of the projects is not in Kotlin, it should be possible to have all projects with kotlin, that should not be an issue, although to be clear, do you have all the subprojects in the same repository? The issue might arise if you have multiple settings.kts in the same repository, because teamcity expects a single one to have as the project one. Otherwise, you can use the non-portable DSL instead of the portable one
Is it possible to have nested kotlin scripts (I.e. settings.kts) within a single repository? In the same way that maven or helm can be made aware of child configurations.. From the JB articles I have seen, it suggests you can’t - but then another article says you can provided you disable portable kotlin scripts, you can! If the answer is yes, can you please link an example of how this is done; even if the only way is through per repo per project.
Hi Alexander,
Can you share that article here?
Thank you,
Guilherme