How do I show GitHub commits and pull requests beside logs from Vercel projects for an AI SRE?

Tares shows GitHub commits and pull requests beside Vercel logs when both sources carry the same service label, so they merge into one time-ordered timeline for that service. Your AI SRE reads that timeline and checks whether the first error lines start after a commit or a merged pull request. You set this up with a vercel source for the log drain and a github source for the repository, each with a primary label named service.

How it works

Tares builds one timeline per service from every source that carries the same primary label, as described in Build an AI SRE. The two sources start with different default keys, so you align them.

• The Vercel connector creates one event per log entry. Its default key is project, with environment and source as labels. It also provides path, host, deployment and branch.
• The GitHub connector with a personal token polls a repository every 2 minutes by default. It reports commits (event_type of commit) and pull requests opened, merged or closed (event_type of pull_request). Its default key is repo.
• You add a label named service to both sources and mark it primary. On the Vercel source it reads the project field. On the GitHub source it is a constant that equals the Vercel project name.

Because both sources now share service, Tares merges commits, pull requests and log lines on one clock. The agent reads that one timeline instead of querying two systems. GitHub events also carry sha, title, author, branch and action, so the agent can name the change that preceded the errors.

Set it up

1. Create the vercel source. In the console choose Sources → Add source → vercel, or ask a connected agent to create it. Replace the default project label with a primary service label that reads the project field.
2. Copy the source’s ingest endpoint. In Vercel go to Team Settings → Log Drains → Add Log Drain, set the endpoint to that URL and the delivery format to JSON. Vercel delivers from its cloud, so the endpoint must be publicly reachable: use a deployed instance or a tunnel. A bare localhost daemon does not receive drains.
3. If your Tares has auth on (tares up --auth), add a custom header to the drain: Authorization with a Bearer value holding an ingest-scoped API key. Without auth, the drain needs no header.
4. Create a GitHub credential under Settings > GitHub with Add a personal token. Give it Metadata, Contents and Pull requests read access. Without Pull requests read, commits still arrive but pull requests do not.
5. Add one github source per repository, with the same service value as your Vercel project name:

- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: service, field: project, primary: true }
      - { name: environment, field: environment }
      - { name: source, field: source }
- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: repo, field: repo }

6. Open Recent events on the Vercel source and Fields to confirm service is filled. Then open Explore, pick the service, and check that commits, pull requests and log lines appear together.
7. Ask your connected agent: “Use tares: did the errors on checkout start after a change?” The agent reads the service timeline and compares the first error lines with the nearest commit or merged pull request.

What you get

• One timeline per service with deploy-relevant changes and log lines in time order.
• An agent that can say “the merge landed, then errors began” or “errors began before any change”, citing the sha, title and author from the GitHub event and the log lines from Vercel.
• Triggers that work on the same labels. For example, a trigger on the github source with event_type equal to pull_request and action equal to merged fires once per merged pull request.
• Logs split by environment (production or preview) and source (such as lambda, build or edge), so the agent can separate preview noise from production errors.
• Several Vercel projects through one drain. Each project appears as a distinct entity, and each one lines up with its own repository through the shared label value.

When something else fits

• If you want pushes, reviews, releases and CI runs rather than commits and pull requests, connect the GitHub App on the same GitHub page. It delivers events by webhook, covers every installed repository in one source, and needs a Tares that GitHub can reach.
• If a repository feeds several Vercel projects, or one project spans several repositories, keep a separate github source per repository and give each the service value of the project it deploys.

Related