Skip to content

fix(comments): keep a writer failure apart from the git grep status - #16

Merged
github-actions[bot] merged 1 commit into
mainfrom
fix/768-scanner-status
Oct 25, 2026
Merged

github-actions[bot] merged 1 commit into
mainfrom
fix/768-scanner-status

Conversation

@znerol2

@znerol2 znerol2 commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

Summary

The review-history check reads exit status 1 from git grep as "no match". A failed output redirection also exits 1, so if writing a work file failed after the check had truncated it, the result came back empty and the scan was skipped without an error.

  • Each git grep call writes its own exit status to a separate file, from inside the redirected block.
  • If that file is missing or not a single integer, the check exits 1 with an error. Otherwise the existing handling of 0, 1 and higher statuses applies.
  • The docstring scan step already treats any non-zero status as an error, so it doesn't change.

The scanner matches the other repos' copies. Only this repo's exclude list differs.

Testing

  • bin/check-review-comments.sh --self-test passes. It has a case for each wrapped call, where a git wrapper on PATH makes the status file unwritable as the targeted git grep starts. Both cases fail with exit 0 when a missing status is read as "no match".
  • bin/check-review-comments.sh gives the same result as before this change.
  • shellcheck bin/check-review-comments.sh is clean.

Refs dmfdeploy/dmfdeploy#768

The check treats exit 1 from git grep as "no match". A redirection that
fails after the work file was truncated also exits 1, so a later write
failure could leave an empty result and skip the scan without an error.

Write each command's own status to a separate file from inside the
redirected block. If that file is missing or not a single integer, the
redirection or the status write failed, and the check exits 1 with an
error. Otherwise the existing 0, 1 and greater-than-1 handling applies.
The docstring scan step already treats any non-zero status as an error,
so it needs no change.

The self-test gains a case for each wrapped call. A PATH shim makes the
status file unwritable just as the targeted git grep starts, with no
seam in the script.

Refs dmfdeploy/dmfdeploy#768

Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com>
@znerol2
znerol2 requested a review from a team as a code owner October 25, 2026 22:41
@github-actions
github-actions Bot enabled auto-merge (rebase) October 25, 2026 22:42

@lkirc lkirc left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static review of 91717d1 found no blocking issues.

The separate recorded statuses make both scan paths fail closed when their exit status cannot be written.

@github-actions
github-actions Bot merged commit 764e422 into main Oct 25, 2026
10 checks passed
@znerol2
znerol2 deleted the fix/768-scanner-status branch November 5, 2026 08:18
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