Repository navigation
ci: gate PRs on scripts/quality.sh - #5
Closed
pluginslab wants to merge 1 commit into
Closed
pluginslab wants to merge 1 commit into
pluginslab wants to merge 1 commit into
Conversation
The kit ships a pre-commit hook, a quality script, and a 56-case test suite for its own hooks — and none of it ran on a pull request. A gate that only fires on the machine of whoever happens to be committing is a convention, not a gate. CI calls scripts/quality.sh rather than re-listing the checks, so there is one definition of "quality" shared by the hook, a local run, and the runner. A check that exists only in CI is a check that surprises you on a PR. Pinned to PHP 8.2 because that is what the plugin template's header declares. Same reasoning playground-verifier applies when it boots at the declared minimum instead of at latest: gate on the version you claim to support, not on whatever the runner happens to ship. No composer.lock is committed, so the install resolves fresh. That is deliberate — it catches an upstream release breaking the scaffold before a user hits it on `composer install` after `npm create wp-ai-plugin`. Verified by simulating the run locally: `git archive HEAD` into a clean tree with no vendor/, then composer install + quality.sh. Green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pluginslab
force-pushed
the
ci/quality-gate
branch
from
September 16, 2026 21:23
36dc5d3 to
bec1ed1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The kit ships a pre-commit hook, a quality script, and a test suite for its own hooks — and none of it ran on a pull request.
scripts/quality.sheven carries a header comment claiming CI as a caller:There was no GitHub Actions. A gate that only fires on the machine of whoever happens to be committing is a convention, not a gate — and this repo's entire pitch is the difference between those two things.
What
One workflow,
qualityonpush: mainand everypull_request. It calls./scripts/quality.shrather than re-listing the checks, so there is a single definition of "quality" shared by the hook, a local run, and the runner. A check that exists only in CI is a check that surprises you on a PR.Three decisions worth a look:
Pinned to PHP 8.2. That's what the plugin template's header declares (
Requires PHP: 8.2). Gate on the version you claim to support, not on whatever the runner ships. Same reasoningplayground-verifierapplies when it boots at declared minimums instead of latest. Happy to add a matrix if you'd rather also catch forward-compat breaks — I left it single-version because a green matrix that flakes on aphpunit/PHP-8.4 interaction is worse than an honest single check.No
composer.lockis committed, so the install resolves fresh. That's deliberate rather than an oversight to fix: it means CI catches an upstream release breaking the scaffold before a user hits it oncomposer installafternpm create wp-ai-plugin. The tradeoff is non-hermetic builds — an upstream break turns CI red on an unrelated PR. I think that's the right trade for a scaffold whose job is to work on someone else's fresh machine, but it's a judgement call and reversible.Read-only
permissions, and concurrency cancels superseded runs.What this deliberately cannot do
Boot WordPress.
playground-verifieris the kit's runtime gate and it needs an agent harness plus thewp-playgroundMCP server, neither of which exists in a GitHub runner. The workflow says so in a comment, because the failure mode here is someone seeing a green check and assuming the plugin runs. It doesn't prove that. v1.0.2 shipped a scaffold that fataled on activation through checks exactly this green.Static analysis is the floor, not the ceiling.
Verification
Simulated the runner locally rather than pushing and hoping:
git archive HEADinto a clean tree with novendor/, thencomposer install --prefer-dist --no-progress --no-interaction, then./scripts/quality.sh. Green, 56 assertions (this branch is offmain; #3 takes that to 99 and #4 to 109).YAML validated.
Note
.github/is in the CLI'sREMOVE_AFTER_EXTRACTlist, so this workflow does not ship into scaffolded plugins — it gates the kit only. Whether generated plugins should get a CI workflow of their own is a real question and a bigger one; not touching it here.Branch protection has to be set in repo settings; I haven't touched those. Once this merges,
quality.shis available as a required check onmain.🤖 Generated with Claude Code