Repository navigation
support for automatic steps #40
Description
In the path towards automation, the idea of the runbook is to slowly swap out individual steps / methods in the class for automated actions, eventually cutting out the humans entirely. To facilitate this we need the concept of an automated step, one which does not prompt but performs an action and logs it.
Considerations include acceptance criteria, whether the user should confirm the action or just let it happen, repeatability, etc. Also right now the methods are invoked to return dynamic doc strings, so this behavior might be in conflict if the method has to run.
Some possible implementations:
def _deploy_cf_stack():
pass
def deploy_cf_stack(action='_deploy_cf_stack'):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""def deploy_cf_stack(auto=True):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""
def action_fn():
self.helper.deployStack()
return StepInfo(description="dynamic docs!", action=action_fn)def deploy_cf_stack(with_action):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""
def action_fn():
self.helper.deployStack()
with_action(action_fn)
return "dynamic docs"def deploy_cf_stack(action):
"""
Deploys the CloudFormation stack with parameters
derived from the previous steps.
"""
@action
def do_deploy():
self.helper.deployStack()
return "dynamic docs"
Activity
brhodes77 commentedon Nov 24, 2019
I've just recently discovered this repo, after experimenting with the Ruby runbook implementation out of braintree. Having the ability to easily mix manual and automated steps is a key feature for us and I'm wondering if you'd consider an implementation where the method simply IS the automated implementation when auto=True. I think this would be very intuitive and make it about as simple as possible to add in automated steps, keeping runbooks pretty clean. The downside is that you would loose support for dynamic doc generation, but I didn't totally follow the use case around that and how important that is. Here's what it would look like, given your examples above:
With all this said, if the dynamic doc feature is important (or if I'm missing something else), then I'd vote for the 2nd option you posted above, which is fairly similar. It adds more required boilerplate to turn on the automation, which can add up and potentially take away from runbook readability, but perhaps a reasonable trade off. In our use case, I'm not anticipating using the dynamic doc feature.