[jgautheron]

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.

^{Written for commit b0f6890. Summary will update on new commits.}

[CLAassistant]

All committers have signed the CLA.

[cubic-dev-ai]

No issues found across 1 file

_{View guided diff | Re-trigger cubic}

[gjkim42]

/kelos review

[kelos-bot]

🤖 Kelos Task Status

Task kelos-reviewer-issue-comment-1b536ed7d99d has succeeded. ✅

[kelos-bot]

🤖 Kelos Reviewer Agent @gjkim42

Review Summary

Verdict: APPROVE
Overall correctness: patch is correct
Scope: Adds pull-requests: read to the job-level permissions block of check-pr-labels in .github/workflows/label.yaml.

Findings Overview

Priority	Count	File:Line	Summary
P0	0	—	none
P1	0	—	none
P2	0	—	none
P3	1	commit b0f6890 / PR description	Says the check fails on every PR, but in this repo it passes with only issues: read

Findings

Accuracy

• [P3] commit b0f6890 / PR description — Both say check-pr-labels "fails on every pull request with Resource not accessible by integration" and is "unauthorized by construction, regardless of repository settings". CI in kelos-dev/kelos shows otherwise. With a token limited to Issues: read and Metadata: read, listLabelsOnIssue succeeds on pull requests. This PR's own pull_request_target run (37645162938) logs All required labels are present. Run 37182809079 correctly reported Blocking labels found: needs-kind, needs-release-note. GitHub's REST docs list either Issues: read or Pull requests: read as enough for this endpoint. The change itself is fine, but the commit message will stay in history and tells future readers the gate was broken when it was not. Suggested rewording: "grant the pull-requests scope explicitly so the check does not rely on the issues scope covering pull requests". If you saw the 403 in a specific environment, such as a private repo, name it instead.

Key takeaways

• The diff is one line, read-only, and scoped to a single job. pull-requests: read is the correct scope for reading a pull request's labels, and no write access is added.
• I could not reproduce the failure the PR describes in this repo, so this change hardens the job rather than fixing a broken gate. It is still worth merging.
• check-pr-labels runs on pull_request_target, so its workflow definition comes from the base branch. The new permission takes effect only after merge, and checks on this PR still run with the old block.