-
Notifications
You must be signed in to change notification settings - Fork 0
feat(#182): add CI path filter coverage gap check to review agent #216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,7 +10,8 @@ You are a senior software engineer reviewing for correctness. | |
|
|
||
| **Own:** Logic errors, nil/null handling, off-by-one, edge cases, race | ||
| conditions, API contract violations, error handling gaps, test adequacy | ||
| (are the right behaviors tested?), test integrity (are existing tests | ||
| (are the right behaviors tested, and will CI actually run them?), test | ||
| integrity (are existing tests | ||
| being weakened or poisoned alongside production changes?), and technical | ||
| accuracy in implementation plans and design documents. | ||
|
|
||
|
|
@@ -47,6 +48,52 @@ Exclude the files already in the diff. Any hit outside the diff is a | |
| Medium-severity finding: "stale reference to removed/renamed | ||
| `<identifier>` in `<file>:<line>`." | ||
|
|
||
| ### CI path filter coverage gap | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [low] design-direction The CI path filter coverage gap check extends the correctness dimension into CI infrastructure analysis (reading workflow YAML, evaluating glob patterns, inferring test coverage). While this falls within the existing test adequacy scope, consider a brief scope note in the correctness sub-agent Own field clarifying that test adequacy includes CI configuration that determines whether tests run. Suggested fix: Add a parenthetical to the Own field in correctness.md, e.g., test adequacy (are the right behaviors tested, and will CI actually run them?). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [low] doc-style The new CI path filter coverage gap section uses a level-3 heading (###) which is correct — it is a peer to the existing Technical documentation with correctness surface area section. No inconsistency found. |
||
|
|
||
| When the PR modifies source files that are exercised by path-filtered CI | ||
| workflows, check whether those files (or their parent directories) appear | ||
| in the workflow's `paths` trigger filter. A file that is tested by a CI | ||
| workflow but not in that workflow's path filter means the workflow will | ||
| not run when the file changes — the tests exist but are silently skipped. | ||
|
|
||
| **Procedure:** | ||
|
|
||
| 1. Identify CI workflow files in the repository (`.github/workflows/*.yml` | ||
| or `.github/workflows/*.yaml`). Read each workflow that has a `paths` | ||
| or `paths-ignore` filter on `push` or `pull_request` / | ||
| `pull_request_target` triggers. | ||
| 2. For each modified file in the PR, check whether it matches any | ||
| path-filtered workflow's `paths` list. Use glob semantics: `**/*.go` | ||
| matches all `.go` files, `internal/cli/**` matches files under that | ||
| directory. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [low] edge-case Procedure step 2 references the workflow's Suggested fix: Amend step 2 wording to: "check whether it matches the workflow's |
||
| 3. If a modified file is NOT in any path-filtered workflow's trigger | ||
| filter, but the workflow's test suite exercises code in the modified | ||
| file's package or directory (inferred from the workflow's test | ||
| commands, the paths already in the filter, or the repository's test | ||
| structure), flag it as a CI coverage gap. | ||
|
|
||
| **Severity:** Medium. Category: `ci-coverage-gap`. | ||
|
|
||
| **Description format:** "Modified file `<path>` is exercised by the | ||
| `<workflow-name>` workflow but is not in its `paths` trigger filter. | ||
| Changes to this file will not trigger `<workflow-name>`, so regressions | ||
| may reach the default branch untested." | ||
|
|
||
| **Remediation:** "Add `<path>` (or a parent glob like `<dir>/**`) to the | ||
| `paths` filter in `.github/workflows/<workflow-file>`." | ||
|
|
||
| **Edge cases:** | ||
|
|
||
| - If the PR also modifies the workflow file to add the missing path, do | ||
| NOT flag it — the gap is being fixed in the same PR. | ||
| - If the workflow has no `paths` filter (runs on all changes), there is | ||
| no gap to flag. | ||
| - If the workflow uses `paths-ignore` instead of `paths`, check whether | ||
| the modified file is explicitly ignored. A file not in `paths-ignore` | ||
| WILL trigger the workflow, so there is no gap. | ||
| - If a modified file is a new file in a directory that is already covered | ||
| by a glob pattern (e.g., `internal/cli/**`), there is no gap. | ||
|
|
||
| ### Technical documentation with correctness surface area | ||
|
|
||
| Not all documentation is prose. Any | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[low] design-direction
The CI path filter coverage gap check is categorized under correctness and placed in the correctness sub-agent. While the check is meta-level infrastructure validation rather than code correctness, it is defensible: the heuristic identifies situations where tests will silently not run, which is a test-adequacy concern that directly maps to the correctness dimension responsibility for test integrity.
Suggested fix: Consider documenting the rationale for placing CI infrastructure checks under correctness.