mirror of
https://github.com/HDFGroup/hdf5.git
synced 2026-09-25 04:09:44 +03:00
Scot BreitenfeldandH. Joe Lee
0f1dfcc08e
* fix(review-checklist): re-request dismissed reviewer on fixup push When a new commit dismisses a prior reviewer's approval, GitHub's CODEOWNERS engine auto-assigns a fresh (possibly different) owner for the changed area. The synchronize handler now detects dismissed area-owners and swaps them back in, removing the fresh CODEOWNERS pick. Adds planSynchronizeSwaps() pure helper (exported) with 7 unit tests covering the PR 6475 scenario and edge cases. * fix(review-checklist): don't remove a fresh pick still needed by another area planSynchronizeSwaps could remove a fresh CODEOWNERS pick to restore a dismissed reviewer even when that pick also covered a different, unrelated touched area — removeRequestedReviewers strips them from the whole PR, silently uncovering the other area. Now skips removal when the candidate owns any other touched area. Also dedupes the consuming loop so a login needed by two areas isn't requested/removed twice. 5 new tests covering the cross-area guard and its boundaries. * fix(review-checklist): don't let bot's own reviewer removal create a sticky exclusion The bot's own removeUnselected/removeRequestedReviewers calls (draft-opened CODEOWNERS cleanup, stale-exclusion enforcement) fire review_request_removed, which the workflow also listens on — self-triggering another run. That run previously read its own bookkeeping removal as a deliberate human decision and added the login to the persisted exclusion set, permanently blocking that owner from ever being auto-assigned to the PR again. Guard on sender.type !== 'Bot' so only human-driven removals become sticky. * fix(review-checklist): prune CODEOWNERS avalanche regardless of which event wins the race GitHub's CODEOWNERS engine fires one review_requested event per auto-assigned owner on PR creation, and each re-triggers this workflow. With concurrency: cancel-in-progress, whichever run starts last wins — and that's just as likely to be one of those review_requested runs as the opened run itself. A surviving review_requested run fell through to the additive-fill branch, saw every area already "covered" by the avalanche, and pruned nothing. This hit PR #6479 itself: all 4 CODEOWNERS for .github/ stayed requested. Branch on whether a checklist comment exists yet instead of which action survived — that signal is race-resistant: no comment means this is the PR's first coordination pass no matter which event got here. Threads hasExistingComment through from run() (defaulting to true, i.e. additive-fill, on a comment-fetch failure so an API hiccup can't be mistaken for a fresh PR). 2 new tests: the #6479 race itself, and a contrast case confirming a routine review_requested on an already-established PR still uses additive-fill. --------- Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>