Make the CI check report on every PR

[erikdarlingdata]

Prerequisite for requiring CI on dev. Doing it in the other order would break the repo.

The problem

ci.yml skipped itself on docs-only changes via workflow-level paths-ignore. That's harmless while nothing depends on the check, and fatal the moment it's required: a workflow skipped by a path filter reports nothing at all, so GitHub leaves the required check pending forever and the PR can never merge.

PR #535 (screenshots and README) would have been permanently unmergeable.

The fix

The filtering moves into the job. The job always runs, so the check always reports; the steps that cost anything are guarded with if: and skip on a docs-only change. A skipped step still lets the job finish green.

This is the shape PerformanceMonitor's build.yml already uses, and its own comment spells out the same reasoning about checks that never report.

One detail worth flagging

The filter is a positive list of code paths, not the old ignore list inverted. dorny/paths-filter ORs the patterns within a filter, so a stack of negated patterns matches whenever a file fails any one of them — for a docs-only change that's always true, and it would have reported code=true for every PR, quietly defeating the point. Listing what is code can't fail that way.

PlanViewer.Ssms and PlanViewer.Ssms.Installer stay out, matching the old behaviour: they aren't in PlanViewer.sln and ci.yml never built them.

Once this is in, build-and-test gets added as a required check on dev.

🤖 Generated with Claude Code

[claude]

Reviewed. This does what it says: the job now always runs and reports, only the expensive steps are gated by if:, and the positive-list filter correctly matches the four projects actually in PlanViewer.sln (PlanViewer.App, PlanViewer.Cli, PlanViewer.Core, PlanViewer.Web, tests/PlanViewer.Core.Tests) plus the build inputs that affect them (src/Directory.Build.props, global.json, the workflow file itself). PlanViewer.Ssms/.Installer staying out matches prior behavior since they're not in the solution. dorny/paths-filter@v4 and actions/checkout@v7/actions/setup-dotnet@v6 are real, current tags, and the "OR of negations always true" reasoning for switching to a positive list is correct.

One thing worth double-checking, not a blocker: the old paths-ignore only applied to the pull_request trigger — push: branches: [main] always ran the full build unconditionally. The new job-level filter applies uniformly to both triggers, so a doc-only push to main (e.g. a docs-only merge) will now also skip build/test on the push-triggered run, which is a small behavior change beyond "make the required check report." Probably fine/desirable, but wasn't called out in the description.