I'm doing some maintenance on our lite ETL in Workflows. This has been working for us since June 2023, no issue with run history. My concern here is that it has a status of "Undeployed changes" which I have not done any changes in this workflow. I'm assuming this is a version up or changes in retool workflows and nothing to do with my blocks at all. I have two things to ask here:
How do you check changes like this? Checking my previous release does not provide a good comparison to identify what has changed. One I can think of is exporting the workflow (current and previous release).
What's the best practice for undeployed changes like this? "If ain't broken, don't fix it!" or "Release the beast!"
I am hyper-aware of that little deploy button. It is the first thing I look at when I open a workflow (usually to check on a previous run history) and the last thing I look at before I close a workflow.
Something as innocuous as shifted node will register as a deployable change.
I made a feature request for allowing me to check historical runs without needing to enter the workflow for just this reason.
I am not sure if this use case works for you, but if you are sure that the previous release is what you need, could you deploy the new version and then revert to the right one?
Thanks for the reply! Yeah, I'm kinda same with the deploy button though I'm fairly certain that the placement of my workflow nodes have not changed since I have not touched this workflow since we deployed it.
I thought that it is something similar to Retool Apps where comparing changes for release, you'd notice the cloud app version number changes.
Your suggestion is something I'd avoid as I rely on previous workflow run timestamp for this ETL.
EDIT: My suggested solution does not work. I was trying to export the previous deployed version but it only gave me the current version's json file. Ha!
This allows you to see previous versions but, unfortunately, doesn't give you an itemized list of individual changes. If your workflow still runs as expected when scheduled or triggered, you should feel pretty confident discarding any undocumented changes!
For relatively complex workflows, in particular, I think there could be a lot of value in a granular change log. I'll talk to the team to see if that would be a feasible feature!
Right, I'll do that then and revert to the initial release. Thanks!
Yeah, having granular change log would be amazing. But there's no urgency on my end for that. I have a few complex ones but I've documented them well and maintain them every month or so.
