Skip to content

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

Open
brtnfld wants to merge 4 commits into
HDFGroup:developfrom
brtnfld:fix-release-progress-issue-field
Open

brtnfld wants to merge 4 commits into
HDFGroup:developfrom
brtnfld:fix-release-progress-issue-field

Conversation

@brtnfld

@brtnfld brtnfld commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Fix release-progress badges to read the native issue-level Priority field instead of the previous lookup
  • Show TBD on the Next Release badge when no milestone due date is set
  • Update the release-schedule diagram (image and PlantUML source) to match what the readme says
  • Fix the review-checklist bot mistaking GitHub's own CODEOWNERS auto-assignment for a deliberate manual reviewer add on a PR's first coordination pass, which could permanently flag an auto-assigned owner (e.g. a catch-all * owner) as requiring separate approval on every PR touching their area

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.
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.
@github-actions

github-actions Bot commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Review Checklist

This PR touches the following areas. Each needs a sign-off
from its listed owners before merging.

@github-actions
github-actions Bot removed the request for review from glennsong09 September 11, 2026 22:40
…R'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.
@github-actions
github-actions Bot removed the request for review from hyoklee September 11, 2026 22:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: To be triaged

Development

Successfully merging this pull request may close these issues.

2 participants