1) using a retool-workflows-helm, moving to retool-helm 6.0.2 ... pre Retool image 3.6.11
workflows: enabled would have been set; if it's not set for some reason, we won't spin up workers as expected.
we continue to respect any other fields related to workflows as is (codeExecutor, retool-temporal-services-helm)
2) using a retool-workflows-helm, moving to retool-helm 6.0.2 ... post Retool image 3.6.11
workflows: enabled would have been set; if it's not set for some reason, we will spin up workers + backend (but worker will not CrashLoopBackOff)
we continue to respect any other fields related to workflows as is (codeExecutor, retool-temporal-services-helm)
3) using retool-helm <= 5.0.10, moving to retool-helm 6.0.2 ... pre Retool image 3.6.11
if you wanted workflows, you MUST set explicitly since these workers will CrashLoopBackOff without temporal config (connecting to external cluster) OR retool-temporal-services helm spinning up a local cluster.
if you don't want workflows, you can set nothing -- and we will not spin up workflows.
we continue to respect any other fields related to workflows as is (codeExecutor, retool-temporal-services-helm)
Baseline
Migration/upgrade scenarios:
1) using a
retool-workflows-helm
, moving toretool-helm
6.0.2 ... pre Retool image 3.6.11workflows: enabled
would have been set; if it's not set for some reason, we won't spin up workers as expected.2) using a
retool-workflows-helm
, moving toretool-helm
6.0.2 ... post Retool image 3.6.11workflows: enabled
would have been set; if it's not set for some reason, we will spin up workers + backend (but worker will not CrashLoopBackOff)3) using
retool-helm
<= 5.0.10, moving toretool-helm
6.0.2 ... pre Retool image 3.6.114) using
retool-helm
<= 5.0.10, moving toretool-helm
6.0.2 ... post Retool image 3.6.11workflows: enabled
tofalse