Bill Gernert
Automation & Tooling

Python tooling

The glue that automates the platform - small, idempotent scripts with one canonical way to do each task, secrets fetched in memory, and tools that bootstrap their own auth instead of assuming the box is already set up.

What it is & why I use it

A lot of AutomationLab is held together by Python: the helpers that open pull requests, allocate addresses, register hosts, and talk to the platform's many APIs. These scripts are the connective tissue between the big tools - the part that makes a pipeline one flow instead of a stack of manual steps.

I treat this glue as real software, not throwaway. It is versioned, reviewed, and built so anyone (including a fresh automation run on a box that has never done this before) gets the same result. Convenience scripts that only work on the author's machine are how a platform quietly becomes un-runnable by anyone else.

How I use it in the lab

  • One canonical way per task. Opening a pull request, for example, has a single script that does it correctly - so the tricky parts are solved once, in one place, instead of rediscovered each time.
  • Secrets fetched, never stored. Tools that need a credential pull it from the secrets manager at run time and hold it in memory - never written to disk, never passed as a command-line argument where it would leak into history.
  • Idempotent and re-runnable. Scripts are written so running them twice is safe - they converge to the intended state rather than blindly repeating side effects.
  • Self-bootstrapping auth. Rather than assuming an already-authenticated CLI is present, the credential helpers can establish their own scoped login, so the same tool works on any box (see the gotcha).

Architecture

Diagram coming A helper: bootstrap a scoped login -> fetch the one secret it needs -> call the API in memory -> exit, leaving nothing on disk. Scrubbed of endpoints and secret paths.

In action

Screenshot coming The PR-opening helper running on a fresh box, bootstrapping its own auth and succeeding with no token file present. Captured per the publishing checklist - endpoints and any token material redacted.

Lessons learned & gotchas

Gotcha - "works on my machine" is an ambient-state bug The trap in glue code is silently depending on ambient state - an already-authenticated CLI, a config file, an environment variable that happens to be set on the author's box. It runs perfectly there and fails the moment it lands on a fresh agent or a different operating system, usually with a confusing auth or path error rather than an honest "I need X." The fix is to make tools self-sufficient: fetch the secret they need directly (falling back to bootstrapping their own scoped login when no authenticated client is present), and never assume the environment has been hand-prepared. A tool that only works where it was written is not automation - it is a manual step wearing a script's clothes.
  • Keep secrets off disk and out of argv. A token in a temp file or a command argument leaks into backups, logs, and shell history. Fetch it, use it in memory, discard it - the safest place for a secret is nowhere persistent.
  • Cross-platform on purpose. The lab is driven from more than one operating system, so tools use the portable invocation rather than assuming one shell's paths and binaries. "It only runs on Linux" is a limitation you discover at the worst time.
  • Idempotence beats cleverness. A re-runnable script that converges is worth more than a clever one that only works if the starting state is exactly right - because in practice the starting state never is.

Impact

1 way
per task, solved once
0
secrets on disk
Any box
same result

The Python glue is what makes the platform's many tools behave as one system rather than a set of tricks that only the author can run. The lasting lesson is to treat glue code as software with the same standards as everything else: no ambient assumptions, no secrets on disk, and idempotence by default - so the automation actually runs anywhere, not just where it was born.

Code & further reading

Helper scripts (link coming) The Zen of Python

Published scripts are scrubbed of endpoints, hostnames, secret paths, and any token material before they go public; credentials always come from the secrets manager.