[no-ci] Add assignee check to PR metadata check workflow

[rwgk]

Extends the PR metadata check (#1815) to also require at least one assignee.

Changes

• Add assignee check: fail with "Missing assignee" if no one is assigned
• Trigger on assigned / unassigned events so the check re-runs when assignees change
• Order all references (workflow name, env vars, check logic, summary output) to match the GitHub UI sidebar order: Assignees, Labels, Milestone

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[rwgk]

Why pr-metadata-check.yml cannot trigger on milestone changes

The workflow uses pull_request_target, which does not support milestoned or demilestoned as activity types. These types are only valid for pull_request.

Evidence

• actionlint (run via pre-commit) rejects milestoned / demilestoned under pull_request_target and lists the valid types explicitly.
• The GitHub docs for pull_request list milestoned and demilestoned as valid activity types.
• The GitHub docs for pull_request_target do not include them.

Practical impact

When someone assigns or removes a milestone, the metadata check does not re-run automatically. However, the next synchronize (push), labeled, or assigned event will re-trigger the check and pick up the current milestone state. The check can also be re-run manually from the Actions UI.

Could we switch to pull_request?

pull_request supports milestoned / demilestoned, but it changes the security model: the workflow file is read from the PR head branch, not from main. This means a fork PR author could modify the check to make it pass unconditionally.

For a metadata-only check that uses no secrets and only reads the event payload, this is arguably acceptable. But it is a deliberate trade-off.

Decision

Stay on pull_request_target and accept that milestone changes don't auto-trigger the check. The trade-off (slight inconvenience vs. tamper-proof check) favors keeping pull_request_target.

[rwgk]

Why pr-metadata-check.yml does not check GitHub Projects "Status"

Labels, milestone, and assignees are first-class PR fields available directly in the pull_request event payload. GitHub Projects v2 status is not — it lives behind a separate GraphQL API.

What it would take

• A GraphQL query against projectItems on the PR node, extracting fieldValueByName(name: "Status").
• The default GITHUB_TOKEN permissions likely don't include read:project. You'd need to add permissions: projects: read (or use a PAT / GitHub App token if org-level projects restrict access).

Where it's brittle

• The field name "Status" and option values like "Todo", "In Progress" are user-configured strings in the project UI — renaming them silently breaks the check.
• A PR might not be in the project yet (no project item), which needs a separate decision: fail or skip?
• If the project is org-owned vs. repo-owned, the GraphQL query shape differs slightly.

Rough GraphQL sketch

query($owner: String!, $repo: String!, $pr: Int!) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $pr) {
      projectItems(first: 10) {
        nodes {
          fieldValueByName(name: "Status") {
            ... on ProjectV2ItemFieldSingleSelectValue {
              name
            }
          }
        }
      }
    }
  }
}

Recommendation

Hold off on this check. If you want to gate on readiness, a label like blocked or do not merge (already checked by the workflow) is more reliable than querying project status.

[cpcloud]

What is the motivation here? Are we really going to fail a PR because it doesn't have an assignee?

[rwgk]

I saw @leofang going through many times assigning me after PRs were merged. That made me think it must have a purpose. I was also thinking it's in line with enforcing labels and milestones.

[cpcloud]

Still not understanding what the motivation here is. We shouldn't add more process requirements to code review.

For the record, I am against this change as it creates more work and things to remember for no obvious reason.

[rwgk]

I can totally see that consistency going forward will make tracking and summarizing easier for management.

The only slight issue I see is that we can currently not assign "partners" (as discussed in our team meeting), but IIUC that's about to change.

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.