coraislovely-code 3d207ed125 Report PHPCS findings per changed line, and make the job advisory ...

The first version of this job ran PHPCS over every file a pull request touched. Running it
for real showed why that does not work here.

This plugin predates the WordPress coding standards by about a decade, and its files carry
hundreds of pre-existing findings apiece -- 406 on the files one of the follow-up branches
touches. Scoping by file means the job fails the moment a pull request edits a legacy file,
whether or not that change made anything worse, and a job that is red by default is one
everyone learns to scroll past. That is worse than not having it.

So report per changed LINE instead: findings on lines a pull request adds are shown, and the
historical backlog stays quiet until someone chooses to work on it. The diff is taken against
the merge base rather than the base branch tip, so a base branch that has moved on since the
pull request opened does not drag unrelated commits in.

Even scoped that way it is advisory rather than a gate, which the first real run also made
clear. Of the findings on one branch's added lines, most cannot reasonably be fixed: the
sniffs cannot see through apply_filters() to an escaper inside it, cannot know that an
interpolated ORDER BY direction was whitelisted against ASC/DESC, and object to the
$before_title/$after_title arguments that every WordPress widget emits. Gating on those would
mean scattering phpcs:ignore annotations through unrelated changes, which makes the code
worse to read in exchange for a green tick. Pass --strict to make it blocking if that
tradeoff ever looks worthwhile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-25 13:36:31 -04:00

..

scripts

Report PHPCS findings per changed line, and make the job advisory

2026-07-25 13:36:31 -04:00

workflows

Report PHPCS findings per changed line, and make the job advisory

2026-07-25 13:36:31 -04:00