How to have a global parameter that is not a context parameter and read it from Kotlin DSL ?
Hi, I want to have a global parameter that I can read from Kotlin DSL. I am aware of context parameters but if I use those then I won't be able to edit TeamCity from the UI.
Regular parameters do not resolve in custom Kotlin files I add to the project (this does not work: “%my_param%”), so just having a parameter at the root project level is not an option (unless you pass it around to functions in each of the builds where you need it).
What other options do we have to:
- have a global parameter/property
- be able to edit the UI
- be able to get the value in a custom Kotlin file
Use case:
I want to have a flag to enable/disable certain features at the project level. The idea is to have `enabled = isEnabled()` where `isEnabled()` would be getting some parameter value + some extra logic. I managed to make this work using context parameters, but as said, I want to be able to edit settings via UI.
Please sign in to leave a comment.
Please refer to the related feature request: https://youtrack.jetbrains.com/issue/TW-63565.
And the comment with the workaround that may be useful for your use case: https://youtrack.jetbrains.com/issue/TW-63565/Allow-editing-projects-using-parameterized-Kotlin-DSL#focus=Comments-27-3847626.0-0.
There seem to be no other way to implement what you need, so please let me know if this workaround is helpful.
Best regards,
Anton
hi Anton,
I have left a comment in that issue now. If you use context parameters in your project you basically “lock” the UI with no way to unlock it from UI. The workaround I was putting in place so far was to have all references to context parameters in a single wrapper class and if I needed to do some changes that must be done via UI (like for example setting up a Github app connection, or creating a VCS root that uses that connection via Github app access token) then I would comment out the context parameters code and make it return some dummy values so I can make my changes in UI and then I'd uncomment the code back (and squash the commits that got pushed via UI to have a clear Git history of changes we do in TeamCity).
The workaround of using
teamcity.ui.settings.readOnlyis not applicable because context parameters take priority over that.I think not being able to have a way to have some global properties set and still be able to edit via UI is a missing feature.
Thanks
David
I'm glad that you have a workaround that works for you, and I understand that it's not ideal. Thank you for commenting in the issue. There is no roadmap for this feature yet, but please keep an eye on it in case of further development.
Best regards,
Anton