Do-nothing scripting: the key to gradual automation (2019)

In general it's another way of defining interfaces around processes. Those processes may be manually done or automated. But the interface can remain the same - this is quite powerful when it comes to automating steps.

It's the same as you'd do with another system really.

I've used this before with Google sheets being manually filled in -> automated with a script. And with Jira tickets being raised and then automatically picked up and processed. It lets you get started sooner, automated the most annoying parts and you never have to fully do it.

Side benefit of do nothing scripts is that they can remain up to date more often as they can be more likely to be actually used than reading the docs.

However the task used as an example just shows how provisionning SSH keys was insecure at that company. In fact the user should generate his private key by himself and just provide the public key to the sysadmin to inject it in the system to grant access. AT NO POINT THE SYSDAMIN SHOULD HAVE A COPY OF THE PRIVATE KEY, even temporary. So the 1Password step shouldn't even be necessary.

By the way, I'm the author of github-keygen, a tool to automate the creation of SSH keys dedicated to GitHub access, and to setup SSH settings for that context.

https://github.com/dolmen/github-keygen

Due to bugs in our toolchain we had a run book for hot fixes that was about twice as complicated as the normal release process.

I never got the credit it deserved but it went from people only using it for sev 1 issues and “last mile” work in epics that were winding up, say once every ten weeks, to using it on average once a week and a couple times 3 in one week. We were able to dig a lot deeper into tech debt because not every single thing had to be a feature toggle.

If you’re at a small company where cloning prod data into preprod is easy, you won’t see this sort of result. But I counted over 150 endpoints we talked to and I believe that averaged 3 per service. So that’s a lot of datasets, and some of them ingested in a Kafka-before-Kafka-existed sort of manner. We had only one guy who would even try to clone prod data, he only had the time (and really energy) to do it once or twice a year, and that was much slower than our customers and features morphed. So it was down to fiddling with the blue-green deployment process and jmeter to figure out if we were close and how to measure success/failure before we went live.

And in the end it was the fiddly error-prone build process that stymied people until I half-automated it.

Later on as we ramped up its use I hunted down all of the URLs for the manual steps and put them in a lookup table in the tool, and ended up exposing them for the normal validation process we did for release sign off as well. Which made that process a little faster and less stressful for the coordinator (that process was annoying enough that we round robined it through three separate teams to share the load)

Does that mean the "do-nothing script" should eventually have some automated steps that do-something?

As a placeholder for future possible automation, this feels like the right balance between automation and efficiency. It allows you to make the first stab without investing too much and it leaves some low-hanging fruit for another time when the effort might be more obviously worthwhile. Thanks for sharing!

  class Foo(object):
      def run(self, context): ...

  def foo(context): ...

It would also be nice if it would show you all the steps beforehand, and then check each item as you progress. Sometimes it's good to actually prepare from a broader perspective.

And it could log into a file as a summary.

So much that could be improved, which is why the simplest solution might be the best.

https://news.ycombinator.com/item?id=29083367 - 3 years ago (230 comments)

https://news.ycombinator.com/item?id=20495739 - 6 years ago (124 comments)

I've successfully applied this approach to so many projects. My favorite example is a $30 million surgical robot that was failing labs because of the "human factor".

Interface "not implemented" errors follow a similar logic but I honestly think the value of writing something trivial that gives a meaningless but valid output for each of a bunch of pieces that depend on each other goes a long way toward expediting the process of building those pieces. It makes it much more likely you can test and build one thing at a time and not need to write a bunch of separate parts before you can test any of them

Having this type-wise validity matter in scripting contexts is sometimes harder, as in the use case described in the article, as a lot of the effects of command lines are going to be "side effects" from a functional perspective, but it being sequential makes this a lot less impactful and the waiting prompts make it so you can still preserve order of tasks at the low cost of needing manual steps you'd be doing without the script anyway

Scaffolds are incomplete but they're still, fundamentally, useful

I’ve written a lot of automation and documentation for ops teams and getting them to use it, and use it constantly, has always been an issue. Doc changes also needed announcements, as people quickly stop reading them once they know how to do something.

In a perfect world, I think the approach makes a lot of sense, and I might even use it for some personal stuff. In practice the world is rarely perfect, and I think I’d only employ this if 90% was automated, but there was still 1 step I couldn’t quite get… and even then, I could see some members on the ops team skipping the manual step and assuming the whole thing is automated and magic.

Otherwise, it'd be trivially easy for an unfamiliar user (or the automated script) to ignore unclear errors or exit codes and march blindly to the next wait_for_enter().

2. Automate the runbook

3. Delete the runbook

This is just a means to get #2 done iteratively. I've done variations for a while, its a powerful technique.

1) Add a “Quick Run” section with just the steps/commands absent images and details, so it’s easier to perform routine slogs without having to scroll through unnecessary information.

2) Make (and link!) a companion code document that has the pseudocode for the process written out, so folks can contribute to it as time allows. If I’m a manager, I’d even incentivize it somehow - maybe covering a team lunch if we convert an SOP into an automation, for instance.

In the meantime, I am totally cribbing this for documenting my homelab stuff and getting it out of Obsidian, as a means of encouraging me to automate routine tasks somehow.

Sadly, because it's associated with learners/juniors, pseudo code gets a bad rap. But really, all engineering is translating English into code ... which means almost any complex operation (setting up a new employee's account, or anything else) can be made clearer by utilizing such an "in-between English and code" step.

In the article they used Python, but for all the important stuff, they didn't: they used English. A "do-nothing" script is really just a script where instead of converting pseudo code to code (like programmers normally do), you just leave the English/pseudo code in, and wrap it with a print.

It's a thought technology which I suspect will result in better final scripts than what I have tended to do, which is much more linear and requires a significant refactoring step at the end to avoid having one long function of poor quality.

One Note also has the ability to add checkboxes as dot points, and you can make “template pages” for each procedure and then you can then just right click -> duplicate, and use the checkboxes to keep track of where you get upto in a process.

The reason this is great for me is because I virtually never get to sit still and finish anything unless it takes less than 1 min. People pull my attention in every direction.

Tool: https://tools.o14.ai/do-nothing.html

Blogged about here: https://shekhargulati.com/2025/02/16/do-nothing-script-gener...

So I built a script that tells me what the first step is. When it's done I run the script again and it tells me what to do next. Often the first few steps are "download this CSV from the bank" so the script can detect I've done than and go directly to the next step when I rerun the script

The reason I have a script I rerun rather than a "press enter to continue" is because it then only keeps persistent state, and I can easily do a bit every day until done

A common pattern is

    if ! [[ -e checked-all-the-receipts ]]; then
         echo "check that the receipts match the list of expenses, then"
         echo "  touch checked-all-the-receipts"
         exit 0
    fi

The article even mentions “just another checkbox checked”.

I once saw an SRE get managed out because he kept talking about “reducing toil” and his director eventually said, “he obviously didn’t like toiling here so we helped him leave.”

Like, sometimes you can automate 99% of a procedure, except like putting a secret into an so-far not automated secret management solution, or running a terraform apply that requires access to something that's not accessible from the automation just yet.

Instead of giving up there, I now just go ahead and insert e.g. an `ansible.builtin.pause` with clear instructions to the user what to do, and when to continue the play. This might not be gloriously fully automated (yet), but it is so much better than having to do the other 12 things manually.

Similar, we have "standard plays", which are just shell scripts to invoke ansible in some specific way. But those have started to accrue some user guidance and some do-nothing instruction steps as well. The database creation script asks you if you've added the database in the three other places upon startup, since it'd fail otherwise. Or a disk resize standard play asks you if you need to resize the disk on a failover cluster as well now?

I would like to have these things fully automated, but having these simple scripts as guidance for admins is surprisingly valuable.

The reason it is helpful for decreasing activation energy is that it handles the "checklist" aspect of creating a user account for you. This is especially helpful for user account creation, which has to be done completely and then logged or it can lead to cybersecurity incidents.

I tried automatizing those with some tools intended for gui testing, but those solutions tend to be brittle and I just don’t feel well if I cannot get a real success report.

I’d be fretful for somthing that solves that problem.

I find the idea of setting up “do nothing workflows” that I can compose and implement more thoroughly over time helpful. I’ll probably put this into use.

In PowerShell especially there are elegant ways to prompt users for “continue y/n?”.

MM, interesting idea.

[0] https://github.com/MattSayar/post_to_socials

I follow the advice of this column, but I differ in my implementation. It is lightweight and not so OO.

Confluence is fantastic for runbooks. It's accessible to all kinds of users, you don't have to grant access to them, you get comments, people can edit on the fly without a review, the content is versioned, and most importantly, includes mixed media. My runbooks are often a mix of video clips, screenshots, text, and links to other pages.

In order to automate the runbooks, I do a couple things:

1) I write little scriptlets and either drop them into the runbook as one-liners, or commit them to a `./bin/` directory in a repo with some basic documentation. 1a) If I write a script, usually I make it so it takes some arguments and produces output, so that it can be modified later in a backwards-compatible way, and so it can be composed-with. Every time I do this, I'm making automation easier later on.

2) I have a deployment wrapper `deploy.sh`, and a CI/CD job that calls the wrapper. If I make my scriptlets call-able from `deploy.sh`, then my scriptlets get to take advantage of all the environment set-up my CI/CD job did, so I don't have to do any more work to get the CI/CD system to call my scriptlet. And since my CI/CD job can take parameters and pass them onto `deploy.sh`, and `deploy.sh` can pass arguments to my scriptlet, and my scriptlet can take arguments, I can now re-use the one CI/CD job I made, to call my scriptlet, from any CI/CD pipeline, or from a one-time API call to the CI/CD provider with parameters.

3) I have a Slack bot that'll take commands from Slack and call the CI/CD job with parameters. Now I'm enabling chat users to call automation from Slack, reusing the CI/CD, reusing the deploy.sh, reusing my scriptlets, enabling users to call automation from their chat window.

4) I modify the Slack bot to allow users to edit cron jobs (really just scheduled CI/CD jobs) to run tasks on a regular basis. Now they can either use pre-written scripts, or write their own, and schedule them to run regularly.

Now, my day job has quite a few different responsibilities (as all Sysadmi-cough I mean "DevOps Engineers"- tend to have), so I don't have time to build all this in one go at each job I work at. I build the whole thing slowly over time. As each new feature is available, I release it for use: first the Confluence runbooks, then the scriptlets, then the CI/CD jobs, then the Slack bot. It takes about two years for all of it to be ready. But once it is, it's amazing how much productivity a whole team of people gets out of it.

If I was allowed to do all this automation at once, we'd reap the benefits much sooner. But people who have never seen the rewards of automation never prioritize it.

run it with `uv run --script script.py`

    #!/usr/bin/env -S uv run --script
    # /// script
    # requires-python = ">=3.13"
    # dependencies = [
    #     "rich",
    # ]
    # ///
    
    # run using `./script.py` or `uv run --script script.py`
    
    import argparse
    from rich import print
    from rich.prompt import Prompt
    from rich.panel import Panel
    
    
    def print_title(text):
        print(Panel(f" {text}", style="green"))
        print("\n")
    
    def print_desc(text):
        print(f"[yellow] {text}[/yellow]")
    
    def print_command(text):
        print(f"[white]{text}[/white]")
    
    def user_input(prompt):
        print("\n")
        return Prompt.ask(f"\n[red] {prompt}[/red]")
    
    def wait_for_enter(dummy_flag):
        print("\n")
        print(Panel(f" Press enter to continue", title_align="center", style="blue"))
        input()
    
    class CreateSSHKeypairStep:
        def run(self, context):
            print_title("Generating SSH Key Pair")
            print_desc("Run:")
            print_command(f"ssh-keygen -t rsa -f {context['key_path']}/{context['username']}.pub")
            wait_for_enter(True)
    
    class GitCommitStep:
        def run(self, context):
            print_title("Committing SSH Key to Git Repository")
            print_desc("Run:")
            print_command(f"cp {context['key_path']}/{context['username']}.pub user_keys/")
            print_command(f"git commit {context['username']}")
            print_command("git push")
            wait_for_enter(True)
    
    class WaitForBuildStep:
        build_url = "http://example.com/builds/user_keys"
        def run(self, context):
            print_title("Waiting for Build Job to Finish")
            print_desc(f"Wait for the build job at {self.build_url} to finish")
            wait_for_enter(True)
    
    class RetrieveUserEmailStep:
        dir_url = "http://example.com/directory"
        def run(self, context):
            print_title("Retrieving User Email")
            print_desc(f"Go to {self.dir_url}")
            print_desc(f"Find the email address for user `{context['username']}`")
            context["email"] = user_input("Paste the email address and press enter")
    
    class SendPrivateKeyStep:
        def run(self, context):
            print_title("Sending Private Key")
            print_desc("Go to 1Password")
            print_desc(f"Paste the contents of {context['key_path']}/{context['username']} into a new document")
            print_desc(f"Share the document with {context['email']}")
            wait_for_enter(True)
    
    if __name__ == "__main__":
        parser = argparse.ArgumentParser(description="Automate SSH key setup and sharing process.")
        parser.add_argument("username", type=str, help="Username for whom the SSH key will be generated")
        parser.add_argument("--key-path", type=str, default=".", help="Path where the SSH key will be stored (default: .)")
        parser.add_argument("--extra-args", nargs="*", help="Additional arguments for future use")
        
        args = parser.parse_args()
        
        context = {
            "username": args.username,
            "key_path": args.key_path,
            "extra_args": args.extra_args or []
        }
        
        procedure = [
            CreateSSHKeypairStep(),
            GitCommitStep(),
            WaitForBuildStep(),
            RetrieveUserEmailStep(),
            SendPrivateKeyStep(),
        ]
        
        for step in procedure:
            step.run(context)
        
        print("[green] Done.[/green]")

    class CreateSSHKeypairStep(object):
        def run(self, context):
            keyfile = os.path.expanduser("~/{0}_ssh_key".format(context["username"]))
            pubkey = keyfile + ".pub"
            if os.path.exists(keyfile):
                print("Key file {} already exists. Skipping generation.".format(keyfile))
            else:
                print("Generating SSH key pair (no passphrase) in {} and {}.".format(keyfile, pubkey))
                cmd = ["ssh-keygen", "-t", "rsa", "-f", keyfile, "-N", ""]
                subprocess.check_call(cmd)
            # Save the key filenames in the context for later use.
            context["keyfile"] = keyfile
            context["pubkey"] = pubkey
            wait_for_enter()

https://pexpect.readthedocs.io/en/stable/overview.html

Don't pretend to yourselves that presenting a series of instructions and only advancing on when someone clicks enter will prevent people hit enter.

Even worse is someone missed up there's no going back. You have to either restart the whole process or you have to go and read over the python script.

This is not something that prevents or helps with slog.