How do I send GitHub App events to an AI SRE?

Tares receives GitHub App events as webhooks in a single github source that covers every repository the App is installed on. Each event arrives as it happens, labeled with the repository, and your triggers and agents can act on it. If you only need commits and pull requests, a personal token polls them instead, and a Vercel log drain covers deploy and runtime logs keyed by project.

How it works

You pick a credential and Tares decides how events arrive.

• GitHub App (recommended): GitHub pushes events by webhook as they happen. They include pull requests, pushes, reviews, review comments, comments, issues, releases and CI runs. One source covers every repository the App is installed on.
• Personal token: Tares polls every 2 minutes by default. It reads commits and pull requests that are opened, merged or closed. You add one source per repository.
• Vercel log drain: a push source. You point a Vercel log drain at the source’s ingest URL, and each log entry becomes one event keyed by project, with environment and source as labels. See Vercel logs.

Both GitHub paths produce the same events, so a trigger keeps working when you switch from a token to the App. Every event carries labels such as repo, action, number, author, branch, sha, title and conclusion for CI runs, and each event type has a key that ties it to the service:

Every delivery is checked against the App’s webhook secret before anything is stored. An unsigned or wrongly signed request gets a 401. A delivery GitHub sends twice is stored once.

Set it up

1. Connect the App.
   • On Tares Cloud, open your workspace settings, choose Connect GitHub, pick the organization and repositories, and confirm on GitHub. Your workspace gets a github source carrying every event of those repositories.
   • Self-hosted, open Settings > GitHub and choose Create GitHub App. Enter the organization (leave it empty for your own account) and check the address under Address and App name. Choose Continue on GitHub and confirm the permissions and events. Back in Tares, choose Install on GitHub, pick the repositories and install. Tares stores the App as a credential and creates the github source. You paste nothing by hand.
2. Make Tares reachable. GitHub must reach your Tares for webhooks to arrive. A local tares up is not reachable from the internet, so run a tunnel and use its address as the public URL:

cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up

You can create the App without a tunnel. Deliveries start once Tares is reachable. 3. Key a trigger to the service. Filter on the labels the events carry. This trigger fires once per merged pull request in two repositories:

- name: pr-merged
  sources: [github]
  filters:
    - { field: event_type, op: eq, value: pull_request }
    - { field: action, op: eq, value: merged }
    - { field: repo, op: in, value: [acme/checkout-api, acme/payments] }
  condition: { aggregate: count, predicate: "> 0", window: 5m }
  cooldown: 5m

4. Optional, use a token instead. Create a fine-grained token with Metadata, Contents and Pull requests read. Under Settings > GitHub, choose Add a personal token and paste it. Then add a source per repository:

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: repo, field: repo, primary: true }

5. Optional, add Vercel logs. Create a vercel source, copy its ingest URL, and add a log drain in Vercel under Team Settings, Log Drains with delivery format JSON. The endpoint must be publicly reachable, because Vercel delivers from its cloud.

If you already have an App, add it under Settings > GitHub through the API with its app id, private key, webhook secret and installation ids, then point the App’s webhook at the github source’s ingest URL.

What you get

• Pull requests, pushes, reviews, issues, releases and CI runs from every installed repository in one github source, delivered as they happen.
• Labels like repo, action, author and conclusion that your triggers and agents filter on, so an alert for acme/checkout-api stays tied to that service.
• Agents that act as the App (your-app[bot]), so every write they make on GitHub shows as the App.
• Check runs from agents. An agent can post its verdict on a pull request as a pass, fail or neutral result in the pull request’s checks, with notes on the lines it is about. Ask for it in the agent’s instructions.
• Signed, deduplicated deliveries. Refused requests are counted on the credential’s row in Settings > GitHub.
• Vercel log entries keyed by project, so a deploy log lines up next to the pull request that shipped it.

If deliveries do not show up, check that Tares is reachable at the address the App uses and that the App is installed on the repository. GitHub’s App settings list recent deliveries under Advanced. A 401 means the webhook secret on GitHub does not match the credential’s, so reconnect from Settings > GitHub.

When something else fits

• Personal token: choose it when you want commits and pull request open, merge and close events for a few repositories and do not want to create an App. The first poll imports recent commits and no old pull requests, and a pull request reopened between two polls is not reported. Agents act as the token’s user, and they cannot post check runs. See GitHub for the full field list, including api_url for GitHub Enterprise.
• Vercel log drain: choose it when the signal you need is runtime, build or edge logs rather than repository activity. It is keyed by project, not by repository. See Vercel logs.
• Both: run the App and a Vercel source side by side when you want code changes and deploy logs in one place.

Related