Repository navigation
Describe a safer pattern to replace pull_request_target - #309
Conversation
Document the build / signal / workflow_run split that lets projects comment on, label and publish from fork pull requests without pull_request_target, with an example from apache/magpie-site. Generated-by: Claude Opus 5
|
Go for it @cottage14 :) |
There was a problem hiding this comment.
github-actions-policy.md
line 39: change the last sentence from passive to active voice: "You can do all of these without 'pull_request_target' by splitting the work across three workflows so that no privileged job ever runs, or even sees, code from the pull request."
line 43: change passive to active voice; "Do the privileged work in workflow_run, which starts when the build workflow or the signal workflow completes. GitHub always runs workflow_run from the default branch, so its code is your reviewed code, never the contributor's. This workflow may hold a write token; and it downloads the artifacts produced by the build and comments, labels or publishes."
line 86: change the comma to a semicolon after 'steps from it'
Line 96: change the part before the URLs to human-readable: "A complete example that publishes website previews of pull requests, including from forks, is in the Apache Magpie website repository:" Consider making the URLs a bulleted list for easier reading.
Use active voice, fix punctuation and list the Magpie example workflows as bullets. Generated-by: Claude Opus 5
|
@cottage14 thanks for the review! I've applied your suggestions in 65dd6bb:
Could you take another look? |
|
🙇 🙇 🙇 🙇 🙇 |
The policy page tells projects not to use
pull_request_target, but it doesn't say what to use instead. From November 2026 the trigger is disabled for ASF repositories, so projects that relied on it need a replacement.This adds a subsection describing a generic replacement for commenting on, labelling and publishing from fork pull requests:
pull_requestbuild only uploads artifacts;pull_request"signal" workflow does nothing except complete, for events that start no build (labels, close);workflow_runworkflow, which always runs from the default branch, holds the write token and consumes the artifacts as data only.It includes minimal YAML for the signal and privileged workflows, the MUST rules for using the pattern safely (no PR checkout, artifacts as untrusted data, no event values interpolated into
run:, explicitworkflows:list, least-privilegepermissions), and links to a working implementation in apache/magpie-site.Context: Beam is already reworking its workflows to drop
pull_request_target: https://lists.apache.org/thread.html/m2kpyvoq1zcdtosh4s1g4854cxojcdyb🤖 Generated with Claude Code