Skip to content

Add a "consider a lower level" hint for very noisy runs - #1069

Open
skerbis wants to merge 1 commit into
feature/non-blocking-analysis-page-v2from
feature/analysis-priority-hint
Open

Add a "consider a lower level" hint for very noisy runs#1069
skerbis wants to merge 1 commit into
feature/non-blocking-analysis-page-v2from
feature/analysis-priority-hint

Conversation

@skerbis

@skerbis skerbis commented Sep 4, 2026

Copy link
Copy Markdown
Member

Summary

Independent sibling of #1068 (the trigger/UI-polish PR) — both are based on #1067 but not on each other. Reopens the content of #1065 unchanged (that PR was already cleaned up to this minimal diff per @staabm's review), now as a standalone PR instead of the last link in a 5-deep chain.

When a run reports more than 200 problems (a rough heuristic) at a level above 0, a hint now points at the settings page to choose a lower level and work back up from there. PHPStan's levels are themselves already a priority ordering — each level builds on every check from the levels below it — so this uses that existing lever instead of introducing a separate, parallel categorization scheme (an earlier version of this change added exactly such a scheme via a RexStanCategorizer; removed per review feedback).

Touches only lib/RexResultsRenderer.php and CHANGELOG.md.

Test plan

  • Verified the hint appears for a large result set and does not appear for a small one, and links to the settings page correctly.
  • php -l + PHPStan on all changed files: 0 findings.

🤖 Generated with Claude Code

When a run reports more than 200 problems (a rough heuristic) at a
level above 0, a hint now points at the settings page to choose a
lower level and work back up from there. PHPStan's levels are
themselves already a priority ordering - each level builds on every
check from the levels below it - so this uses that existing lever
instead of introducing a separate, parallel categorization scheme.

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

staabm commented Sep 4, 2026

Copy link
Copy Markdown
Member

warum als target branch der große feature branch?

@skerbis

skerbis commented Sep 5, 2026

Copy link
Copy Markdown
Member Author

Weil der Code, den diese PR ändert (RexResultsRenderer::renderAnalysisBody()), in dieser Form erst durch #1067 entsteht - auf main gibt's die Methode so noch gar nicht. Die PR muss also auf #1067s Branch aufsetzen, bis der gemerged ist; danach sollte GitHub den Base-Branch automatisch auf main umstellen.

Ist bewusst kein Stack im klassischen Sinn - die PR hängt nur an #1067, nicht an einer anderen offenen PR. #1068 z.B. ist eine unabhängige Schwester-PR daneben, keine Voraussetzung hier. Hatten wir vorher als 5er-Kette am Laufen, die haben wir extra aufgelöst, weil das unübersichtlich wurde.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants