Skip to content

Revert "Ask callers for pull-requests: read, not write (#48)" - #50

Open
alanshaw wants to merge 1 commit into
mainfrom
ash/fix/pr-run-pull-requests-write
Open

alanshaw wants to merge 1 commit into
mainfrom
ash/fix/pr-run-pull-requests-write

Conversation

@alanshaw

Copy link
Copy Markdown
Member

Reverts #48 and restores pull-requests: write on the check, wait and report jobs of pr-run.yml.

Why

piri's first /forge-perf run, on fil-forge/piri#148 with the pin at 373f9ec, failed in the check job's react step:

gh: Resource not accessible by integration (HTTP 403)

Run: https://github.com/fil-forge/piri/actions/runs/36694053554/job/109817684240

#48 downgraded pull-requests to read on the premise that the reaction, the progress comment and the report go through the issues API, which issues: write covers. That premise does not hold for a pull request. GitHub checks the token's pull-requests permission for a comment whose issue is a pull request, whichever API endpoint it arrives through, so issues: write alone gets a 403 on the very first write. The reaction was only the first place it showed; the wait job's progress comment and the report job's final comment would fail the same way.

Changes

  • pr-run.yml: the check, wait and report jobs ask for pull-requests: write again.
  • docs/operations.md: the caller snippet grants pull-requests: write, and the paragraph after it says why.
  • scripts/ci/tests/workflows_test.sh: the guard that kept write out is replaced by one that requires every job with issues: write to also have pull-requests: write.

Callers need pull-requests: write in their own permissions block as well as a pin on this commit, since a called job only receives what its own block declares. piri's caller-side change is in progress.

🤖 Generated with Claude Code

This reverts commit 373f9ec.

piri's first /forge-perf run (fil-forge/piri#148, pinned to 373f9ec) failed
in the check job's react step with "Resource not accessible by integration
(HTTP 403)". The reaction, the progress comment and the report all go
through the issues API, but GitHub checks pull-requests: write for a
comment whose issue is a pull request, whichever API it arrives through.
issues: write alone does not cover them, so #48's premise was wrong and
every job that writes to the pull request needs pull-requests: write back.

The check, wait and report jobs ask for pull-requests: write again, the
operations doc says why the caller has to grant it, and the test now
requires every job that writes issues to write pull requests too, in place
of the guard that kept write out.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant