Connecting GitHub

The bot reviews pull requests on github.com with the same engine and the same .reviewgate/config.yml as on GitLab. The proper way to connect it is a GitHub App: it gives the bot an identity of its own, short-lived per-installation tokens and a gate through the Checks API. For a quick trial a personal access token is enough.

1. A GitHub App (recommended)

Organisation settings → Developer settings → GitHub Apps → New GitHub App. Of the fields, the permissions and the events are what matter — the rest (name, homepage) is up to you.

Subscribe to events — tick four:

• Pull request — starts a review;
• Pull request review comment — the bot's replies in the threads of its own comments;
• Pull request review — addressing the bot in the body of a review («Review changes» with a comment);
• Issue comment — a question to the bot under the summary (it only appears in the list once the Issues permission is granted).

Generate a private key (Private keys → Generate a private key) and encode it on a single line — line breaks do not survive inside an environment variable:

base64 -w0 reviewgate.private-key.pem   # macOS: base64 -i … | tr -d '\n'

The value goes into GITHUB_APP_PRIVATE_KEY_B64 and the App number into GITHUB_APP_ID. Then install the App on the organisation or on individual repositories (Install App). The full list of variables is in Installation.

A simpler option: a personal access token

Instead of the App pair, GITHUB_TOKEN alone will do — a fine-grained token with Pull requests (write), Contents (read), Commit statuses (write). How it differs from an App:

• comments come from your personal account rather than from a bot account;
• the gate degrades from the Checks API to a commit status — blocking still works, but GitHub truncates the status description to 140 characters;
• the rate limit is shared with everything else you do on GitHub;
• the bot never answers comments from the account whose token it runs on — that is the anti-loop guard. So in PAT mode the conversation is open to everyone else but not to you; a full dialogue needs an App.

2. The webhook

In the App settings (or the repository settings, if you are on a PAT): Webhook → Active. The URL is the bot address with the webhook path:

https://адрес-бота/api/webhooks/github

• Content type — application/json. The form encoding (x-www-form-urlencoded, GitHub's default in the dropdown) is accepted too, with the same body size cap, but json is more honest: the signature is computed over the same bytes you see in the delivery.
• Secret — the same value as GITHUB_WEBHOOK_SECRET. The bot verifies the X-Hub-Signature-256 signature over the raw request body in constant time; a request with no signature, or with somebody else's, gets a 401.

You can check delivery in the same place: Advanced → Recent Deliveries → Redeliver. The expected answer from the bot is 202.

Which events are reviewed

Talking to the bot

In the thread of its own comment the bot answers a reply by itself. The PR conversation on GitHub is not threaded, so under the summary it answers only a direct mention of its account — otherwise it would butt into every human conversation under the PR.

The body of a review («Review changes» with a comment) is the same case: it has no thread of its own, so the bot answers a mention with a separate comment in the conversation. The answer quotes the question, but GitHub will not show them as a linked exchange — that is a limitation of the platform, not of the bot.

What the team sees

• inline comments anchored to diff positions; with committable_suggestions enabled in .reviewgate/config.yml (off by default), some comments carry a ready fix behind the «Commit suggestion» button;
• a summary comment in the PR conversation — it is updated in place rather than multiplied on every push;
• a reviewgate check run — only if the severity gate is on (off by default).