Let the label check read a pull request's labels
What type of PR is this?
/kind bug
What this PR does / why we need it:
check-pr-labels fails on every pull request with Resource not accessible by integration, so the check never actually evaluates the blocking labels it exists to enforce.
The job declares:
permissions:
issues: read
A job-level permissions block replaces the workflow-level one and sets every scope it does not name to none. Reading a pull request's labels requires the pull-requests scope, so issues.listLabelsOnIssue has no scope that permits it — the call is unauthorized by construction, regardless of repository settings.
The sibling sync-labels job is unaffected because it has no job-level block and inherits the workflow-level issues: write + pull-requests: write.
Adding pull-requests: read alongside issues: read fixes it without widening anything else.
Which issue(s) this PR is related to:
N/A
Special notes for your reviewer:
The check is red on every pull request. It reproduces anywhere the workflow runs on a pull request, since it comes from the job's own permissions rather than from a repository setting.
Does this PR introduce a user-facing change?
NONE
Summary by cubic
Fixes the check-pr-labels job so it can actually read a pull request's labels instead of failing every time with Resource not accessible by integration.
The job's own permissions block only granted issues: read, and a job-level block sets every scope it doesn't name to none. Reading a pull request's labels requires the pull-requests scope, so the call was unauthorized by construction. Adding pull-requests: read alongside issues: read fixes it without widening any other scope. sync-labels is unaffected because it has no job-level block and inherits the workflow-level permissions.