How do I send deploy events from CI to Tares?

Tares receives deploy events from CI through a webhook source that your pipeline POSTs to with one curl line. You create the source with event_type deploy and a text template, copy its ingest URL, and add the curl to the deploy step. Each POST lands as a deploy event on that service’s timeline.

How it works

The webhook connector is the catch-all for anything that can send an HTTP request, and a CI pipeline qualifies. Creating a webhook source gives you a stable ingest URL. Your pipeline POSTs JSON to that URL, and Tares stores the payload lossless.

Three settings on the source turn a POST into a readable deploy event:

• event_type: deploy sets a fixed event type for every POST. Without it the default is webhook_event.
• text_template renders a one-line description from payload fields, for example the commit, the author and the message.
• A label marked primary, such as service, reads a payload field into the event envelope. Events from the same service then line up on one timeline.

The result is that your deploys sit next to metrics, logs and alerts for the same service. That is what lets an agent in an AI SRE setup see “deploy landed at 14:02, errors started at 14:04”. Most real root causes are a change, so deploys are one of the most useful sources you can add.

If you want the event time to be the moment of the deploy rather than the moment of arrival, you can also set event_time_field to a payload field that holds an ISO-8601 timestamp.

Set it up

1. Create the webhook source. In the console go to Sources, Add source, webhook. Declare a label for the payload field you correlate on and mark it primary. You can also ask a connected agent to create a webhook source for your CI events, or POST /api/sources with the same object. The response includes the ingest_key.

2. Use this source definition:

- name: deploys
  connector: webhook
  config:
    event_type: deploy
    text_template: 'deploy {commit} by {author}: {message}'
    labels:
      - { name: service, field: service, primary: true }

3. Save the source and copy the ingest endpoint from the source page. It has the form /ingest/ followed by your ingest key.

4. Add one line to the deploy step of your pipeline, run on every deploy. Fill in the values from your CI variables:

curl -X POST https://<your-tares>/ingest/<ingest_key> \
  -H 'content-type: application/json' \
  -d '{"service": "checkout", "commit": "9f2c81d", "author": "dana", "message": "raise db pool size"}'

5. If your Tares instance has auth on, the sender uses a Bearer Authorization header holding an ingest-scoped API key. Creating a push source in the console mints one for it and shows it once, so store it as a secret in your CI system. If auth is off, the header is not needed.

6. Run the pipeline once, or send the curl by hand. Open the source page and check Recent events for the new deploy event. Fields shows which payload fields arrive and how often, which helps you confirm the service label is reliable.

The webhook accepts one JSON object, a list of objects, or NDJSON, so a pipeline that deploys several services at once can send them in a single POST.

What you get

• Every deploy appears as an event of type deploy on the timeline of the service it touched, with a text line such as the commit, author and message.
• Deploys, metrics, logs and alerts for a service share one clock, so a change is visible right beside the symptoms it may have caused.
• Agents that read the timeline, including one woken by a trigger, see the deploy as evidence without any extra tooling.
• The full payload is stored lossless, so fields you did not map into labels are still there for later.
• Setup is one source plus one line in the pipeline, with no connector of your own to write.

When something else fits

• For config changes, add a second webhook source with event_type: config. It works the same way and keeps config events separate from deploys.
• If your CI already sends GitHub webhooks and you want pull requests, pushes and CI runs, the GitHub connector covers those. The curl approach fits best when you want a deploy event you shape yourself.

Related