ci: run Code Quality on every push to an open PR, not only when it opens - #2230
Merged
Conversation
`pull_request.types` was [opened, reopened]. So the quality suite ran ONCE, when the PR was opened, and every commit after that merged unchecked while the PR still showed the first run's green. Observed here today: - #2227 was opened, failed phpcs on pre-existing debt, was fixed by a follow-up push — and the fix was never verified by CI. - #2228's only Code Quality run stayed pinned to its first commit across a merge from development and two further commits, so its checks were describing code that no longer existed. It took a manual workflow_dispatch to find out whether the branch was actually green. The branch list on `push:` does not cover the gap either: it names `feature/**` while the convention in practice is `feat/**` and `fix/**`. Cost is bounded by the existing concurrency block — a new push cancels the in-flight run for the same head ref rather than queueing beside it. hermiq's copy of this workflow omits `types:` entirely, which defaults to including synchronize; this repo is the outlier.
Contributor
Quality Report — ConductionNL/openregister @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| composer | ✅ | ✅ 174/174 | |||
| npm | ✅ | ✅ 555/555 | |||
| PHPUnit | ✅ | ||||
| Newman | ✅ | ||||
| Playwright | ⏭️ |
Quality workflow — 2026-07-31 14:06 UTC
Download the full PDF report from the workflow artifacts.
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
1 participant
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.
The gap
pull_request.typeswas[opened, reopened]. So the quality suite runs once, when the PR is opened, and every commit after that merges unchecked — while the PR still shows the first run's green.Two examples from today, in this repo:
developmentand two further commits. Its checks were describing code that no longer existed, and it took a manualworkflow_dispatchto find out whether the branch was actually green.The
push:branch list does not cover the gap either — it namesfeature/**, while the convention in practice isfeat/**andfix/**, so most branches get nothing there.Why this is the bad kind of gap
A PR that has never been checked shows no checks, and someone notices. A PR checked once, three commits ago, shows green — and looks more trustworthy than it is. That is the same failure shape as the defects this suite exists to catch.
Cost
Bounded by the
concurrencyblock already in the file: a new push cancels the in-flight run for the same head ref rather than queueing beside it. So a burst of pushes costs roughly one full run, not one per commit.For reference, hermiq's copy of this workflow omits
types:entirely, which defaults to[opened, synchronize, reopened]. This repo is the outlier.