ci: run the AI self-review check on pull_request

GitHub blocks pull_request_target by default in public repositories from
December 2, 2026. The ai-self-review workflow now runs on pull_request.
It still checks out and runs the check script of the base branch and no
other code of the pull request. The workflow file itself now comes from
the pull request, so a pull request that changes it can weaken its own
check. .github/CODEOWNERS therefore makes a maintainer the code owner of
the workflows, CODEOWNERS and the check script; this is enforced once the
branch protection of main requires a review from code owners.

Additional changes
- Record the switch in ADR 0002, which supersedes the pull_request_target
  consequence of ADR 0001.
- Skip the comment step for pull requests from forks, whose token is
  read-only, and point their error message to the job summary only.
- Describe the trigger, code owners and fork limits in docs/develop/ai.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assisted-by: Claude Code (claude-opus-5-5)
This commit is contained in:
Bobby Noelte
2026-11-12 22:00:42 +01:00
co-authored by Claude Opus 5.5
parent eb4b34f194
commit 14e439c265
5 changed files with 72 additions and 15 deletions
@@ -0,0 +1,31 @@
# The self-review check runs on pull_request, guarded by code owners
GitHub blocks `pull_request_target` by default in public repositories from December 2, 2026.
The `ai-self-review` workflow of [0001](0001-self-declared-sha-bound-review-gate.md) therefore
runs on `pull_request`. It still checks out and runs the check script of the base branch and no
other code of the pull request, but the workflow file itself now comes from the pull request, so
a pull request can weaken its own check by changing the workflow. `.github/CODEOWNERS` makes a
maintainer the code owner of `.github/workflows/`, `.github/CODEOWNERS` and
`scripts/check_pr_self_review.py`, so such a change needs a maintainer's review. This supersedes
the consequence of 0001 that a pull request cannot weaken its own check.
## Considered Options
- **Keep `pull_request_target` and allow it in an Actions event policy**: rejected, it depends on
a repository setting outside the code.
- **`pull_request` without code owners**: rejected, nothing would force a review of a change that
weakens the check.
## Consequences
- The code owner review is enforced only once the branch protection of `main` requires a review
from code owners.
- A pull request that deletes the workflow gets no check run; if the check is required, the pull
request waits for it and cannot be merged.
- The workflow keeps `pull-requests: write` to comment. The authors of pull requests from the
repository itself can write to it anyway; pull requests from forks get a read-only token, so
the workflow posts no comment for them, and the report is in the job summary only.
- Depending on the approval setting of the repository, runs for pull requests from forks of
first-time contributors wait for a maintainer's approval.
- `pull_request` runs on the merge commit of the pull request, so a pull request with merge
conflicts gets no run; a required check stays pending until the conflicts are resolved.