Allow steps to be required to be run prior to subsequent steps

[pete0emerson]

$ runbooks --version
runbooks version beta-v0.1.6 (Commit: 8fd8a58)

When I run the my-first-runbook example, I see that there is a "skip" button on a check. That appears to be advisory; in other words, there is nothing preventing me from running subsequent steps on the runbook. It changes the color of the box gray (and marked as "skipped") instead of red or green.

I'd like a method for the checks to be enforced prior to moving on to next steps.

In other words, any <Check>, <Command> or <Template> should have an option to be required to be run and optionally exit successfully prior to proceeding to the next step.

This should be optional, and in my opinion, NOT the default. Sometimes I'd want to be able to be in advisory mode. Maybe something like this:

<Check 
  id="check-git-version" 
  path="checks/check-git-version.sh" 
  title="Check Git Version" 
  required=(no|yes|success)
  description="Verify that you're running a specific version of git" 
  failMessage="Hmm, your git version seems off. Try again." 
  successMessage="Success! Well now, look who's got the expected git version.">
...
</Check>

[josh-padnick]

A very interesting use case! Is the idea here that if a block is required=yes then all subsequent blocks are disabled until that block has been run, and if a block is required=success, then it's the same story, but the the given block has to have been successful before subsequent blocks are enabled?

Out of curiosity, what do you see as the use case? Any reason why it wouldn't be sufficient for Runbook consumers to just choose to use a check or not?

[pete0emerson]

I think I was initially surprised that the "skip" button was just a visual indicator, and that expanded into thinking about required steps in the process.

When upgrading our Gitlab server, for example, we have two paths that are almost identical depending on whether or not we're doing a major upgrade as opposed to a minor one. When doing a major upgrade, we might have some extra steps to do (db migrations, for example). Require all the steps that both paths have in common, and make the unique steps optional. I'd rather do that than create two different runbooks for nearly identical workflows.

Imagine it's 2 am in the morning and your Runbook is lengthy, and perhaps it's the first time you've used it. Having safeguards in place to require me to go step-by-step prevents me from doing something out of order that might have bad consequences. I see this as one step further on the path towards fully remediated problem solving. Eventually, the runbook could just run step-by-step with no human interaction whatsoever, as long as all exit codes are 0.

[pete0emerson]

Is the idea here that if a block is required=yes then all subsequent blocks are disabled

Yes. It allows for requiring linear progression. I can also see the use for NOT requiring linear progression, but generally when I think of a runbook, I think of step-by-step instructions to be followed to accomplish a task.