What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can automate a bounded second review of GitHub pull requests with a GitHub Actions workflow, without running a separate always-on webhook receiver. The workflow listens for the relevant pull request or review event, performs a narrowly scoped task, and reports its result through an allowed workflow mechanism. That avoids adding an external service, but it does not prove that every Actions workload is free: the cost depends on current plan allowances, usage, and any infrastructure you add.
Choose the event that matches what should start the review
GitHub exposes separate events for pull request activity, submitted reviews, review edits or dismissals, and comments. Pick only the event that represents the input your automation needs; a change to a PR and a comment on a review diff are not interchangeable triggers. See GitHub’s workflow event reference and webhook event and payload reference.
| What should trigger work | Event | Useful qualification |
|---|---|---|
| Pull request activity, such as opening or updating a PR | pull_request |
Choose the activity types needed by the workflow rather than reacting to every possible activity. |
| A review is submitted, edited, or dismissed | pull_request_review |
For submitted reviews, select the submitted activity type. If approval status matters, inspect github.event.review.state. |
| A comment is added to a line or diff in a review | pull_request_review_comment |
This is distinct from a general issue comment. |
| A general issue or pull-request conversation comment is added | issue_comment |
Use this for conversation comments, not inline review-diff comments. |
Use GitHub Actions unless the event model requires an external receiver
Built-in Actions trigger
For a typical PR review automation, begin with the built-in pull_request trigger. GitHub starts the workflow when the selected event occurs, so no separate always-on webhook service is inherently required. The workflow can then run a bounded check or review task and return findings through a permitted workflow mechanism, such as a check result or an authorized comment, depending on the permissions and implementation.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteKeep the task limited: define which files or changes it evaluates, what kind of findings it can return, and what it must not do. A second reviewer automation should provide assistance, not silently merge code or treat untrusted input as safe.
#1 Best Overall
External webhook receiver
Use a separate endpoint only when you need routing or processing that the built-in workflow trigger cannot provide. An external receiver adds responsibilities: selecting subscriptions, verifying signatures, routing event types, handling duplicate deliveries safely, and protecting any credentials used to start or report workflow work. It also introduces hosting or compute that may cost money.
| Consideration | GitHub Actions trigger | External webhook receiver |
|---|---|---|
| Separate hosting | Not inherently needed for a workflow triggered directly by GitHub. | Required for the receiver; its hosting may introduce costs. |
| Event selection and routing | Configured in workflow trigger settings. | Receiver subscribes to selected event types and routes deliveries, including by event header. |
| Signature verification | Handled by GitHub when it starts the workflow; there is no custom receiver to validate. | Receiver must validate the delivery signature before processing. |
| Duplicate-delivery handling | Implementation-specific; the cited documentation does not establish a comparative retry guarantee. | Design for idempotent handling; use the delivery ID to identify a delivery. |
| Credentials and secrets | Set workflow token permissions narrowly and account for fork restrictions. | Protect receiver secrets and any credentials used to initiate or report work. |
| Usage costs | Depends on the repository’s current Actions allowances, plan, and workload; no universal zero-cost claim is established. | Depends on receiver hosting and any Actions usage it triggers; no comparative billing amount is established. |
Design the workflow as a small, controlled event flow
- Select the event. Configure only the needed trigger and activity types in the workflow. For example, use
pull_requestfor PR changes, orpull_request_reviewwith thesubmittedactivity type when a submitted review is the input. - Apply the trust boundary. Treat PR content, especially content from forks, as untrusted. Do not execute fork-provided code with privileged credentials.
- Run one bounded task. Give the automation a defined review scope and make its output understandable to maintainers. Avoid giving it authority unrelated to that task.
- Return results using allowed permissions. Decide whether the workflow should publish a check result, comment, or another supported result. Grant only the permissions required for that choice.
- Review settings and cost exposure. Check repository and organization Actions settings, required approvals, token scopes, and the account’s current billing terms before relying on the workflow at scale.
Authenticate custom webhook deliveries before doing any work
If an external receiver is necessary, GitHub recommends validating the webhook signature before processing the delivery further. GitHub’s webhook validation documentation explains the procedure.
- Configure a high-entropy webhook secret and keep it out of logs and source code.
- Read the original request body as raw bytes. Compute and compare the expected SHA-256 HMAC signature with the value in
X-Hub-Signature-256; do not parse or transform the body before validation. - Use a constant-time comparison for the supplied and expected signatures.
- Reject an invalid signature before parsing the event, starting a workflow, or taking another action.
- After validation, route using
X-GitHub-Event. ConsiderX-GitHub-Deliverywhen designing idempotent processing; GitHub documents the delivery ID as globally unique, making it useful for recognizing a delivery already handled. - Subscribe only to the event types the receiver will handle, which avoids unnecessary HTTP requests.
Protect fork pull requests and limit workflow permissions
Fork pull requests cross a trust boundary: the proposed code is controlled outside the base repository. GitHub documents that workflows triggered by pull_request for forks receive a read-only token and no repository secrets. That restriction is safer than granting untrusted code access to privileged credentials.
Be especially cautious with pull_request_target. It runs in the context of the base repository and can have elevated trust, including access to secrets and a privileged token. Do not check out and execute fork code in such a workflow. GitHub’s guidance on securely using pull_request_target describes this risk. Repository policy can also affect whether workflows run automatically or require approval; see managing GitHub Actions settings for a repository.
In workflow syntax, set GITHUB_TOKEN permissions explicitly to the minimum needed. GitHub supports read, write, and none for supported permission scopes; when you specify scopes, omitted scopes are set to none. Consult the workflow syntax reference for the permissions available to the workflow’s context.
What “costs nothing” can—and cannot—mean
A workflow using an existing GitHub-hosted trigger can avoid the separate hosting bill and operational burden of a custom receiver. That is an architectural benefit, not proof that every Actions run has zero marginal cost. Actions billing depends on the current plan, account allowances, workload, and applicable settings; those plan-specific terms are not established here. A custom endpoint or compute service can add its own costs even when the workflow itself uses Actions.
Before describing the setup as free for a particular repository, check the current GitHub billing information for that account and estimate the expected workflow usage. If the actual requirement is only to run on PR changes and report bounded findings, start with the built-in trigger and add an external receiver only for a concrete capability it supplies.
Quick Recap
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.
