mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-30 01:16:56 -04:00
c5cf5d1fec
* ci(integrated-benchmark): post the comment from a workflow_run job The benchmark comment never landed on fork PRs (e.g. #391). The original workflow ran on `pull_request`, which means GitHub gives it a read-only `GITHUB_TOKEN` when the PR comes from a fork — `peter-evans/create-or-update-comment` would 403 trying to write back. The workflow guarded the write with `if: github.event.pull_request.head.repo.full_name == github.repository`, so it silently skipped instead of failing. Switch to the standard two-stage pattern: 1. `integrated-benchmark.yml` runs the benchmark and uploads `SUMMARY.md`, the PR number, and the runner OS as a single artifact. It no longer needs `issues` / `pull-requests` write permissions. 2. `integrated-benchmark-comment.yml` (new) is triggered on `workflow_run` of `Integrated-Benchmark` and runs in the base repository's privilege context, where it can post the comment back to a fork PR. It downloads the artifact via the GitHub API (`actions/download-artifact@v8` with `run-id` + `github-token`), sanitises both untrusted values (the artifact comes from a fork-controlled run), then runs the same find/create-or-update sequence the original workflow used. Same gating as before: only success-path runs of `pull_request` events post a comment. Comments from same-repo PRs continue to work; fork PRs now also get them. * ci(integrated-benchmark): resolve PR number from trusted workflow_run trigger Address CodeRabbit's PR-redirection concern on #398: a fork-controlled artifact must not be the source of truth for which PR receives the comment. Move the PR-number resolution into the comment workflow, sourced from `workflow_run` event metadata that GitHub itself fills in: - Same-repo PRs: read directly from `github.event.workflow_run.pull_requests[0].number`. - Fork PRs (where that array is empty): query `gh api repos/$REPO/commits/$HEAD_SHA/pulls` against the BASE repo, using `workflow_run.head_sha` from the same trusted payload. CodeRabbit's suggested fix used `pull_requests[0].number` unconditionally, which would have broken the fork-PR case this workflow exists to fix — GitHub's docs explicitly state that field is empty for fork-triggered runs. Drop `pr-number.txt` from the uploaded artifact entirely. The runner OS is also no longer carried; the matrix only runs on Linux today, and the comment-matching string is hard-coded to `Integrated-Benchmark Report (Linux)`. If the matrix expands later, both halves need updating together.