How do I find the change behind failed deploys in GitHub commits and pull requests?

Tares puts GitHub commits, pushes and pull requests on a timeline, so you can read the change that landed just ahead of the first failed deploy. Connect GitHub, then ask your agent for the last changes before the symptom began. The commit, push or merged pull request sitting closest before it is your first suspect.

How it works

Tares connects to GitHub with a credential, and the credential decides how events arrive.

• GitHub App (recommended). Events arrive as they happen, by webhook. You get pushes, pull requests, reviews, comments, issues, releases and CI runs (workflow_run) for every repository the App is installed on, in one github source.
• Personal token. Tares polls every 2 minutes by default, one source per repository. You get commits (event_type commit) and pull requests opened, merged or closed.

Both ways produce the same events and labels, so a trigger keeps working if you switch from a token to the App. Each event carries labels such as repo, action, author, branch, sha, title and url. CI runs also carry conclusion and workflow. A closed pull request that merged reads merged.

GitHub events are keyed by repository (owner/repo, or owner/repo#number for pull requests). When you investigate failed deploys, you ask about the repository that ships the service and read the events in time order. The change just before the first failure is the one to inspect. Each commit event can also carry its changed files in the payload (the files option, on by default), so you see what the change touched without leaving the timeline.

To see deploys on the same timeline, send each deploy to a webhook source from your CD pipeline. The AI SRE guide shows how: a deploy event lands next to the errors, so you read “deploy landed, errors started two minutes later” directly.

Set it up

1. Connect GitHub.

   • On Tares Cloud, open your workspace settings, choose Connect GitHub, pick the organization and repositories, and confirm on GitHub.
   • On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, continue on GitHub, then choose Install on GitHub and pick the repositories.

2. On a local Tares, make it reachable so GitHub can deliver webhooks. 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

3. Or use a personal token. Create a fine-grained token with Metadata read, Contents read and Pull requests read. Open Settings > GitHub, choose Add a personal token, then add a source per repository under Sources > Add source > GitHub:

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

4. Optionally add a trigger that fires on every merged pull request. This example names the github source that the GitHub App path creates, so it assumes step 1, not the token path:

- 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

5. Start the MCP endpoint and connect your client, as the AI SRE guide shows:

tares mcp

6. Ask for the changes ahead of the symptom, using the repository as the key:

Use tares: what changed in acme/checkout-api in the 30 minutes before the deploys started failing?

The agent reads the events in order. Look at the last push, merged pull_request or commit before the first failure. Check its author, title, sha, url and changed files. With the App, also look for a workflow_run event whose conclusion shows the CI run that failed.

What you get

• One ordered list of what landed in the repository before the first failed deploy: commits, pushes and merged pull requests, each with author, branch, sha, title and link.
• With the App, CI runs and releases on the same timeline, so you see whether a failed run or a release came right before the symptom.
• A merge trigger, if you add one, that wakes an agent the moment a pull request merges, so a change is already on the timeline when a failure follows.
• An agent that names a specific change and ties it to evidence lines, instead of guessing from a failure alone.

For the full connector reference, including every field and troubleshooting, see the GitHub connector page.

When something else fits

• If the failure comes from a config change or a deploy tool and not from code, send those events through a webhook source as the AI SRE guide describes, because GitHub events only show what happened in the repository.
• A personal token reports commits and pull requests opened, merged or closed, but not CI runs, pushes or releases. Choose the GitHub App if the failed run itself is the clue.
• A pull request reopened between two token polls is not reported, so check GitHub directly if the timeline looks short.

Related