How do I put Postgres tables beside GitHub App events?

Tares puts Postgres rows beside GitHub App events when both sources carry the same label value, such as the repository name, marked as the key. GitHub App events already carry a repo label with the value owner/repo. Give your Postgres source a repo label with that same value and set primary: true. Pushes, pull requests and CI runs then share one timeline with the rows that changed.

How it works

Tares builds one timeline per key value. In the AI SRE guide, sources that all carry the same service label are read together on one clock. The same rule applies here: the label has to exist on both sources and hold the same value.

• GitHub App side. The GitHub connector creates a github source for the App’s webhook. Every GitHub event carries the repo label when it applies, with a value like acme/checkout-api. The event types include push, pull_request, release and workflow_run. Events arrive as they happen, for every repository the App is installed on.
• Postgres side. The Postgres connector polls a table on a cursor column and produces one event per new or changed row. A label marked primary becomes the key for that source.
• The join. When a Postgres row’s repo label equals a GitHub event’s repo label, both sit on that repository’s timeline in time order.

If your table has no column holding the repository name, use a const label instead. It stamps every row from that source with a fixed value.

Set it up

1. Connect the GitHub App. On Tares Cloud, choose Connect GitHub in your workspace settings. On a self-hosted Tares, open Settings > GitHub and choose Create GitHub App, then Install on GitHub. A local tares up needs a tunnel and TARES_PUBLIC_URL so GitHub can reach it. Tares then creates the github source for you.
2. Pick the shared label. Use repo, because every GitHub event already carries it. Check what a GitHub event’s repo value looks like, for example acme/checkout-api.
3. Add the Postgres source under Sources > Add source > Postgres. Enter the connection URL, choose Discover, pick the table and keep a cursor column such as updated_at. You can also ask a connected agent to ingest the table.
4. Add a label named repo and mark it primary. If a column holds the repository name, read it with field. Otherwise set a fixed value with const:

- name: orders
  connector: postgres
  poll: 10s
  config:
    dsn: postgresql://user:pass@host:5432/appdb
    table: orders
    cursor_column: updated_at
    columns: id,tenant_id,status,amount,updated_at   # empty = every column
    labels:
      - { name: repo, const: acme/checkout-api, primary: true }
      - { name: status, field: status }

5. Open the Postgres source and check Recent events after the next poll. Fields shows each column’s coverage, so you can confirm the key is always present.
6. Open Explore for that repository. Postgres rows and GitHub App events should appear on the same timeline.

What you get

• One timeline per repository that shows GitHub App events and Postgres rows merged in time order.
• Pushes, pull requests, releases and CI runs next to the application rows that changed around them.
• Events from the App as they arrive, and rows from Postgres on each poll, with no manual stitching.
• A timeline an agent can read as a whole, as in the AI SRE guide, where a trigger wakes an agent with the correlated evidence.

The label value has to match exactly, so acme/checkout-api on one side must not be checkout-api on the other.

When something else fits

• If one table serves many repositories, read the repository from a column with field rather than a const, so each row lands on the right timeline.
• If you only need the commits of one repository and do not want the App, the personal-token path of the GitHub connector polls them. It uses the same repo label, but it does not deliver the App’s other events.

Related