Case Studies How I keep plugin releases honest with automation
How I keep plugin releases honest with automation
TL;DR Releasing a plugin has a checklist that is easy to get wrong under deadline. I moved that checklist into CI: version numbers must agree across every file, the readme must validate, the code must pass lint and the Plugin Check. A release that fails any of those cannot merge, so I cannot ship a broken one by accident.
Shipping a plugin has a checklist, and checklists fail at the worst moment: when you are rushed, tired, or shipping a quick fix. Rather than trust myself to run it perfectly every time, I moved the whole thing into automation. Now a broken or inconsistent release cannot merge. This is that workflow.
The problem with a manual checklist
A WordPress plugin states its version in several places, needs a valid readme for the directory, and should pass basic quality and compliance checks. Doing all of that by hand on every release is fine until the one time you forget the readme's stable tag, or bump the header but not the changelog, and ship a release that will not update cleanly.
The failure mode is not incompetence; it is being human under deadline. The fix is to stop relying on remembering.
The workflow
I put the checklist into CI, where it runs on every change and blocks a release that does not pass.
- Version consistency. WP Plugin Version Guard fails the build if the version disagrees across the header, the readme stable tag, a constant, and the changelog.
- Quality and compliance. WP Plugin CI runs PHP lint, validates the readme, and runs the Plugin Check.
Because these run as required checks, a release with a version mismatch or a broken readme simply cannot merge. The consistency is enforced by the machine, not by my memory.
What this buys me
The value is not that the checks are clever; they are not. It is that they are always run, correctly, regardless of how rushed the release is. I get to stop holding the checklist in my head and trust that if something mechanical is wrong, CI will catch it before it reaches a user.
That frees my attention for the part a machine cannot check: whether the change is actually a good idea and actually works.
What I learned building it
The lesson was that the most valuable automation often guards the most boring mistakes. Nobody means to ship mismatched versions or an invalid readme; they just slip through when attention is elsewhere. Making those slips impossible to merge is worth far more than it looks, because it converts a category of avoidable, embarrassing release bugs into something that simply cannot happen.
The tools behind this are on the GitHub Marketplace, and the rest of my work is in the products section of the site.
FAQ
Why automate a plugin release checklist?
Because a manual checklist fails exactly when you are rushed or tired, which is often release time. Moving the checks into CI means the machine enforces them on every release, so consistency does not depend on you remembering each step correctly under pressure.
What does the automation actually check?
That the version matches across the plugin header, readme stable tag, a version constant, and the changelog; that the readme validates for the directory; and that the code passes PHP lint and the WordPress Plugin Check. If any fails, the release does not proceed.
Does this replace testing?
No. It guards the mechanical consistency and compliance that are easy to get wrong, not the correctness of the feature. It removes a class of avoidable release mistakes so your attention can go to the things a machine cannot check.