search

OpenC3 / cosmos-project

OpenC3 COSMOS Project Configuration Structure
https://openc3.com
Other
12 stars 4 forks source link

Recommendations for configuration control strategy? #13

Closed nickvzorn closed 1 year ago

nickvzorn commented 1 year ago

Hello @jmthomas and @ryanmelt. (Long-time COSMOS user here, pretty happy with the v5 sea change but still learning to appreciate the plugin architecture.) I'm curious if you have recommendations for configuration-controlling changes made to plugins by the online system (such as new or modified target procedures, etc.)? I miss the convenience of version-controlling the entire COSMOS config directly into git. Do you recommend also configuration-controlling the changes inside targets_modified, alongside the plugin's core configuration files at the top level (e.g. PLUGINNAME/targets/TARGETNAME/procedures)? Or perhaps writing a script to manually copy changes over to that core config location? Any nudge would be appreciated, even if it's just to point me to documentation I may have missed. Thanks.

jmthomas commented 1 year ago

If you're using LOCAL_MODE (on by default) then you will get the plugins directory filled with the installed plugins as well as any changes in targets_modified. The idea is that you can configuration manage this entire project and another user will be able to come up with your same configuration (including modifications).

nickvzorn commented 1 year ago

Thanks for the reply! I follow now that you do recommend version-controlling the contents of targets_modified. It is going to take a little getting used to, having scripts, screens, etc live in one of two places forever (the original plugin directory structure and the targets_modified directory. But I get it - the configuration is replicable that way.

Is there a way to rake a new gem (for example, to include in a release) that's nice and tidy, with all the plugin's original and modified scripts/screens/etc included? Or would one need to Download target modified files from tools/admin/targets and manually merge the modifications in order to create such a gem? Again, any advice you're willing to provide would be appreciated.

jmthomas commented 1 year ago

The idea is that they don't live in two places forever ... just during testing and development. At some point you should manually move the files from targets_modified back into the original plugin and re-build and release it (bumping the version of course). You can also use the "Download target modified files" but it should be the same as what is in targets_modified.