If someone wanted to do source control for an auto...
# proj-automation
a
If someone wanted to do source control for an automation, how would you suggest they do it? They want to make sure they can always restore their automations.
h
I'm not sure I follow. How would an automation change over time if it is active?
a
Things alway go wrong, you need to have a backup and restore plan. It could be someone making a mistake, it could be the cluster going down.
h
Oh hmm. Might be a different story between canvas and OHE backups.
It looks like there is an endpoint for tarball storage. So an automation could be setup to backup the other automations on a schedule easily I think. The database would still also need to get backed up for the automation definitions. I'm not sure if that is already backed up automatically.
c
In general you don't want much configured in the automation itself -- if you use plugin triggered automations the plugin itself is source controlled. Contrary to what the agent may occasionally tell you, plugin based automations always freshly load the plugin from the given ref on execution. And you can use ref as a tag or a branch. If a branch (defaults to main) then any change to main automatically gets picked up without needing to adjust the automation config at all. So if you do that, the only thing left is the schedule. You could absolutely create a an API script that would dump the configuration to git and allow you to recreate it from the stored file.
a
I like this notion of moving the smarts outside of the automation. The automation skill hasn't advised this approach, do you have a quick doc or some examples. I get what you are saying and I already move skills outside of an automation, but this seems like a bit more.
We should add this as a best practice for automations.
💯 1
c
I have some in my personal repo but I'll move something into OpenHands/extensions to showcase at least the plugin part + automations part.
🙏 1
👍 1