Scot Breitenfeld 31d9d3c322 Fix release-progress badges to read native issue-level Priority field (#6668) ...

* Fix release-progress badges to read native issue-level Priority field

The Project Priority board field was consolidated into a Priority field
managed at the issue level (GitHub's org-wide custom issue fields), which
the GraphQL API mirrors into projects as ProjectV2ItemIssueFieldValue
instead of ProjectV2ItemFieldSingleSelectValue. The badge script's query
had no fragment for that type, so it silently found zero priority values
and would raise ProjectFieldMissingError on every run.

* Show TBD on the Next Release badge when no milestone due date is set

Previously the badge silently omitted any due-date annotation when the
milestone had none, which read as if the badge just hadn't picked one up.

* Update release-schedule image and plantuml source from add-next-release-badge branch

* Don't flag CODEOWNERS auto-assignment as a manual reviewer add on a PR's first pass

GitHub's own CODEOWNERS engine fires an identical review_requested webhook
(sender type User, not Bot) when it auto-assigns owners at PR-open time. If
one of those survives the cancel-in-progress race as the run that actually
executes, it was mistaken for a human deliberately requesting that reviewer,
permanently flagging them "manually added" and requiring separate approval —
e.g. a catch-all "*" owner also named on a touched area's CODEOWNERS line got
flagged on every PR touching that area, even though no human ever picked them.

Gate the manual-add detection and the sticky per-area assignment on
!isFirstCoordinationPass (no checklist comment posted yet), since that's
exactly the window where GitHub's own auto-assignment is indistinguishable
from a real human pick.

2026-09-15 14:32:55 -05:00

9.7 KiB

904x234px

Raw History