Skip failure issues for invalidated PR merge-ref checkouts - #65408

Implemented in cb5b92a: classification now requires compiler-derived default-checkout ref eligibility and matches only the uniquely named generated checkout; unrelated and actions-folder checkout steps are excluded.

Implemented in cb5b92a: conclusion jobs grant actions: read and pull-requests: read whenever failure-issue classification can run, with compiler permission coverage.

This permissions gap means the new classifier will silently fail (and fall back to return false, i.e. still report failure as expected) in every compiled workflow, because github.rest.pulls.get and github.rest.actions.listJobsForWorkflowRun both require scopes the conclusion job doesn't currently request.

• pulls.get needs pull-requests: read.
• listJobsForWorkflowRun needs actions: read — this one is already granted when conclusionReportFailedJobsEnabled(data) is true (the default), but is otherwise missing.

Since computeConclusionJobPermissions in pkg/workflow/notify_comment.go was not updated to add pull-requests: read (or actions: read unconditionally), this classifier will always hit the catch block in real compiled workflows with default/least-privilege permissions, defeating the purpose of the change.

Please add a conditional pull-requests: read grant (and ensure actions: read is present) in computeConclusionJobPermissions whenever this classifier can run, mirroring the existing pattern for conclusionReportFailedJobsEnabled.

@copilot please address this.

Implemented in cb5b92a: the required actions: read and pull-requests: read scopes are now conditionally granted for failure-issue classification and covered by compiler tests.

The step-name match alone is not a reliable signal that this specific checkout targeted the PR merge ref. The generated "Checkout repository" step name is reused even when checkout.ref / checkout.repository overrides are configured elsewhere in the compiled workflow (see GenerateDefaultCheckoutStep in pkg/workflow/checkout_step_generator.go), and workflows can also emit custom checkout steps with overlapping names.

Combined with the missing pull-requests: read permission (see other comment), a failed checkout step named "Checkout repository" that is actually unrelated to the merge ref (e.g., a sparse/custom checkout of a different repo) could be misclassified as an invalidated merge-ref checkout and silently suppress a real, reportable failure.

Consider scoping the match more precisely — e.g., checking that the failed step belongs to the known default-checkout step and/or verifying the error output references the merge ref / "not found" — before suppressing failure reporting.

@copilot please address this.

Implemented in cb5b92a: the handler checks compiler-derived checkout eligibility and only matches the uniquely named generated default checkout, not cross-repository or overlapping common-name steps.

[/diagnosing-bugs] If listJobsForWorkflowRun or pulls.get fails due to missing pull-requests: read/actions: read scope (as flagged in the other review comment), the catch here silently swallows it as core.warning and returns false — meaning the existing bug this PR fixes (spurious failure issues on invalidated checkouts) will keep happening silently whenever the conclusion job lacks the required permission, with no clear signal pointing back to a permissions problem.

} catch (error) {
  const msg = getErrorMessage(error);
  if (/403|Resource not accessible/i.test(msg)) {
    core.warning(`Could not check PR merge-ref invalidation — missing permissions (grant pull-requests: read / actions: read on the conclusion job): ${msg}`);
  } else {
    core.warning(`Could not check PR merge-ref invalidation: ${msg}`);
  }
  return false;
}

@copilot please address this.

Implemented in cb5b92a: 403 and Resource not accessible failures now warn with the required conclusion-job read scopes; other API failures retain the generic diagnostic.