How do I show GitHub commits and pull requests beside Docker container logs for an AI SRE?

Tares shows GitHub commits and pull requests beside Docker container logs when both sources carry the same service label. Tares merges events that share a label into one timeline per service, in time order. Your AI SRE agent can then check whether the first error lines start after a commit or a merged pull request.

How it works

Tares builds one timeline per service from every source that has the same service label. Put that label on a docker_logs source and on a github source, and their events land on the same clock. This is the same wiring the AI SRE guide uses for metrics, logs and alerts.

• The Docker logs connector tails a running container and stores one event per log line. It needs access to the Docker daemon, so run taresd on the host, or mount the Docker socket and include the Docker CLI in the image.
• The GitHub connector with a personal token polls a repository every 2 minutes by default. It reports commits, and pull requests opened, merged or closed.
• Each GitHub event carries labels such as repo, action, author, sha, title and url. A pull request that merged has the action merged.
• A constant label, written with const, gives every event from a source the same service name. Mark it primary: true on each source.

When you or an agent reads the service, the commit or merge appears among the log lines at the time it happened. The agent compares that moment with the first error line.

Set it up

1. Start Tares with tares up, on a host where taresd can run docker logs for your container.

2. Add the Docker logs source. In Sources > Add source > docker_logs, set container to the container name from docker ps, or to the Compose service name. If the container runs under Compose, also set compose_file so the tail follows restarts. Give it the service label:

- name: logs
  connector: docker_logs
  poll: 5s
  config:
    container: tares-demo-api-server   # the container name (docker ps)
    labels:
      - { name: service, const: api-server, primary: true }

3. Create a GitHub credential. On GitHub, create a fine-grained token for the repository with Metadata read, Contents read and Pull requests read. Open Settings > GitHub, choose Add a personal token, and paste it.

4. Add the GitHub source in Sources > Add source > GitHub. Pick the credential and the repository, and give it the same service label as the logs. Keep repo as a second label so you can still filter by repository:

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

Use the same value, here api-server, in both sources. If it differs by one character, the events land on two separate timelines.

5. Verify each source. Open each source in the console. Recent events shows Docker lines on the next poll and GitHub events after the first GitHub poll. The first GitHub poll imports recent commits and no old pull requests. If no Docker lines arrive, check that taresd can run docker logs on the container.

6. Read the merged timeline. Open Explore and pick api-server. Commits, pull requests and log lines appear in time order. A connected agent reads the same timeline, so you can ask it whether errors began after the last merge.

What you get

• One timeline per service with change events and log lines in time order.
• Agents that can compare the time of a commit or merged pull request with the first error line, instead of guessing from two separate tools.
• Change context with each event: author, branch, commit sha, pull request title and url.
• A trigger option on the same data. A trigger on the github source can filter on event_type and action, for example every merged pull request in a chosen repository.
• Docker lines you can narrow with match or drop, for example ERROR|WARN to keep only errors, or HTTP/1.1" to drop access logs.

When something else fits

• Use the GitHub App instead of a token if you want events as they happen rather than every 2 minutes, plus reviews, issues, releases and CI runs. It reports pull requests and pushes, not individual commits, and your Tares must be reachable from GitHub. A local tares up needs a tunnel.
• If your containers log through an OpenTelemetry pipeline, use OTLP for the logs and keep the same service label on the GitHub source.
• If you want deploys rather than commits as the change signal, send them from your pipeline to a webhook source with the same service label.

Related