Implementing a CloudProfile
Answered
Hi,
The documentation is pretty sparse around how to implement a CloudProfile, basically saying you don't have to. I think I have a case where I do need to do so, but I'm not getting it to work. Specifically, I don't understand how to associate my CloudProfile implementation with my CloudType?
Also, since I basically want to add one new method, can I extend CloudProfileImpl instead of reimplementing CloudProfile from scratch?
Please sign in to leave a comment.
As you correctly mentioned, you don't need to create a CloudProfile neither implement it. The only thing you need to start is to register your own implementation of CloudClientFactory as a spring bean and register itself in CloudRegistrar.
Here you can find a sample of cloud plugin: https://github.com/JetBrains/teamcity-local-cloud. Specifically, the CloudClientFactory implementation is: https://github.com/JetBrains/teamcity-local-cloud/blob/v2.0/src/jetbrains/buildServer/clouds/local/LocalCloudClientFactory.java
Maybe I wasn't clear - I think I have a case where I *do* need to implement a CloudProfile. The specific think I want to accomplish is to save some data between restarts of the TeamCity server - but maybe there is a simpler way to do that than to create a CloudProfile implementation? This is not for the configuration data for the profile itself, which is saved in the CloudClientParameters, but data generated from the running of the system. I figured that the CloudProfile would be a good place for that?
Event if you create your own implementation TC won't use it - it relies on its own implementation. If you need to save some data between TC restarts you can implement the code in CloudClientEx implementation (which maps 1<->1 to profile) and use plugin storage for that: ServerPaths#getPluginDataDirectory
Oh, I see. Thanks, I'll give that a go, then!
As for the documentation, maybe a rephrasing would be a good idea? The current wording hints that you could implement a custom CloudProfile if you have some special requirements.
Instead of "You do not have to implement this interface", how about "This interface is implemented by internal TeamCity classes, you cannot create your own implementation.", or something similar? Perhaps mention that it can be used as a dependency for constructor injection if some property is needed from it?
Implementation of cloud plugins became quite popular recently, we are considering improvements in the documentation to make it easier and more clear.