The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →You can route pull request activity to a bounded automated review using GitHub Actions, without making a separate webhook server a default requirement. Choose the event that matches the work, limit the workflow token’s permissions, and treat contributions from forks as untrusted. Whether the setup costs nothing depends on your current GitHub Actions allowance, workload, and whether you add separately hosted infrastructure; those costs are not established here.
How the review flow works
A small PR review automation has four parts: GitHub emits an event, a workflow or webhook receiver selects it, the automation performs a defined task, and the result is returned through a permitted mechanism. For many repositories, a built-in Actions trigger is the simplest starting point: it avoids the need to operate an always-on receiver. GitHub documents the available workflow events and activity types in its workflow event reference.
As an Amazon Associate I earn from qualifying purchases.
- Choose an event. Match the trigger to the activity you intend to review rather than listening for every repository event.
- Run a bounded task. Have the automation inspect the relevant PR context and produce focused feedback, rather than granting broad repository access.
- Return the result. Use the workflow’s permitted mechanism to report findings; configure only the token permissions required for that action.
Which GitHub event should trigger the work?
PR changes, submitted reviews, inline review comments, and general issue comments are separate event categories. Picking the right one prevents irrelevant runs and makes the automation’s intent clearer.
| What should trigger the automation? | Event | Important detail |
|---|---|---|
| Pull request activity, such as a PR being opened or updated | pull_request |
Select only the activity types needed for the task. GitHub’s event reference describes which activity types can trigger workflows. |
| A review being submitted, edited, or dismissed | pull_request_review |
To run on submission, select the submitted activity type. If approval state matters, inspect github.event.review.state. |
| A comment on a review diff | pull_request_review_comment |
This is distinct from a general issue comment. |
| A general issue or PR conversation comment | issue_comment |
Use this when the trigger is a conversation comment, not an inline diff comment. |
For example, a workflow that checks changes when a PR is opened or updated can use a trigger like this:
#1 Best Overall
on:
pull_request:
types: [opened, synchronize, reopened]This is a trigger illustration, not a complete review system: the job, review logic, and reporting method depend on what the automation is meant to do.
When a separate webhook receiver makes sense
An external receiver is useful when you need routing or processing outside the Actions event model, or already operate a service that handles GitHub deliveries. It also creates responsibilities that a built-in trigger does not hand off to you: hosting the endpoint, validating each delivery, deciding what to do with duplicate deliveries, and managing any credentials used to start work.
GitHub recommends subscribing only to events the receiver will handle, reducing unnecessary HTTP requests. A receiver can route using the X-GitHub-Event header. GitHub also supplies X-GitHub-Delivery, a globally unique delivery ID; recording it to avoid processing the same delivery twice is a sensible idempotency measure, not a guarantee about retry behavior. See GitHub’s webhook events and payloads reference.
Recommended Free Tools
Rank #2
Authenticate webhook deliveries before processing them
If you run a receiver, verify the signature before trusting the payload or triggering work. GitHub’s guidance is explicit: “To ensure that your server only processes webhook deliveries that were sent by GitHub and to ensure that the delivery was not tampered with, you should validate the webhook signature before processing the delivery further.” See GitHub’s webhook validation documentation.
- Configure a high-entropy webhook secret and keep it out of logs and source code.
- Read the original request body as bytes and calculate the expected SHA-256 HMAC using the configured secret.
- Compare the expected value with
X-Hub-Signature-256using a constant-time comparison. - Reject an invalid signature before parsing the payload or starting any job. Only after validation should the receiver inspect the event header and payload.
Verifying the raw body matters: parsing and re-serializing JSON can change its bytes, so the result may no longer be a valid comparison with GitHub’s signature.
Keep fork pull requests outside the trust boundary
Code submitted in a fork is untrusted input. GitHub documents that workflows triggered by pull_request for forked repositories receive a read-only GITHUB_TOKEN and do not receive repository secrets. That restriction helps reduce exposure, but it also limits what a workflow can do.
Do not switch to pull_request_target as a shortcut for gaining write access and then check out and execute the fork’s code. That event runs in the base repository’s context and can have elevated trust, including access to secrets and a privileged token. GitHub explains the risk in its secure-use guidance for pull_request_target. Keep untrusted code away from privileged credentials and workflows.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsGitHub’s security reference also describes a public-repository default policy that blocks pull_request_target for affected repositories, with enforcement dated November 2, 2026. That date was still in the future in the documentation snapshot dated October 7, 2026. Because applicability depends on repository and policy settings, check the current guidance and your repository’s configuration rather than assuming one policy applies everywhere.
Set workflow permissions deliberately
In the workflow’s permissions setting, grant only the scopes the job needs. GitHub supports read, write, or none for supported permissions; when you specify permissions, omitted scopes are set to none. For a task that only reads repository contents, for example, do not grant write access just because another review workflow might need it. If the automation must post a review or comment, determine the required scope for that operation and grant it explicitly.
permissions:
contents: readThis is a restrictive example for a read-only task, not a universal permission block for every review bot. Review the current workflow syntax documentation and the exact operation your job performs before adding permissions.
Check repository settings and costs before relying on the design
Repository and organization settings can affect whether fork workflows run immediately or require approval. Review the repository’s Actions settings and any organization policy using GitHub’s repository Actions settings guide.
A built-in Actions trigger can avoid the extra infrastructure of an external receiver, but that does not establish that every run has zero marginal cost. Current plan-specific allowances, account quotas, and billing conditions are not established here. A separately hosted receiver or compute service can add its own costs. Check the applicable terms and expected workload before describing the design as free.
Quick Recap
Choose the smallest design that fits
- Start with a built-in
pull_requesttrigger when its event model and credential restrictions fit the review task. - Use review or comment events only when those specific actions need to trigger processing.
- Add an external receiver only when external routing or processing is genuinely needed, and take responsibility for signature validation, duplicate handling, and hosting.
- Keep fork code untrusted, minimize token permissions, and check the repository’s fork-workflow approval settings.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
