How far should a runbook go?

After playing a bit with executable blocks, I have been thinking about how far I want to drive this, and where the boundaries should be before a runbook really becomes a program or an app:

  • How much error handling should be part of a script block?
  • Should there be if-else blocks, or handlers for script failure?
  • Can a runbook assume to be connected to e.g. a certain Tailscale network and test that assumption, or should establishing the connection be part of the runbook?

In the end, I wonder at which point a runbook should become a regular script, or even a full application, with proper tests, documentation, and a release cycle.

I would appreciate if others could share their view on where you think that boundary is.

Thanks in advance.

Good question!

How much error handling should be part of a script block?

Personally I would say that this part is up to you - the error handling belongs in the script block, but if the runbook is written in a way that the user is very much “in the loop” then they’re likely to see + react when things go wrong. If the runbook is written to be more hands-off, then more error handling makes sense

Should there be if-else blocks, or handlers for script failure?

IMO this belongs within the block itself. This part is still a WIP, but I’d like for each block to be recognized within the template system, and to be able to use a Jinja expression to determine if a block is allowed to execute

For example, a postgres block might save to its output whether or not a query was successful. Then, a later block can evaluate the following expression and enable/disable itself

output.postgres_block.success == True

The expression gives us the flexibility to encode whatever logic we want, without building a visual “programming language” into the editor. You could use this to make an if/else system, if you really wanted to!

Can a runbook assume to be connected to e.g. a certain Tailscale network and test that assumption, or should establishing the connection be part of the runbook?

It cannot right now, but this is very much something we plan on having in the future. As well as assuming context like env/directory, we will also have

  1. Networking context (tailscale, etc)
  2. Container context (give the runbook a container it should execute within)
  3. more :slight_smile:

I don’t really wish to dictate these things though. Please do share if you think things should happen differently, or otherwise have insight I might have missed.

3 Likes

That’s exactly the point I was trying to express, and I have high hopes that Atuin may nail this point. Thanks for sharing your thoughts!

1 Like