Skip to Content
Tares

How do I write a trigger that fires once for every merged pull request in two specific repositories?

Tares fires once per merged pull request when you write a trigger on the github source with three filters, a count condition and a cooldown. The filters match event_type pull_request, action merged and repo in your two repositories. The console trigger editor offers event_type and action values to pick from, so you do not have to type them.

How it works

A trigger reads events from one or more sources and keeps only the events that pass every filter. Then a condition decides when it fires. For merged pull requests on GitHub, the pieces are:

  • event_type eq pull_request keeps pull request events. Both the GitHub App and a personal token produce them, keyed as owner/repo#number.
  • action eq merged keeps the ones that were merged. A closed pull request that merged reads merged, so you do not need a separate check for closed.
  • repo in a list keeps only the repositories you name, written as owner/name.
  • condition counts the matching events over a 5m window and fires when the count is greater than 0. This gives one firing per pull request.
  • cooldown is set to 5m in the example.

Both the App and a personal token produce the same events, so the trigger keeps working if you switch from a token to the App. The GitHub connector page lists every event type and label.

Set it up

  1. Connect GitHub so a source carries pull request events. With the GitHub App, choose Connect GitHub on Tares Cloud, or Settings > GitHub and Create GitHub App on a self-hosted Tares. The App creates a github source for its webhook, and one source covers every repository the App is installed on. With a personal token, choose Add a personal token in Settings > GitHub, then add a source per repository.
  2. Make sure both repositories are covered. For the App, install it on both. For a token, add a source for each repository.
  3. Open the trigger editor in the console and choose the GitHub source. When you add a filter on event_type or action, the editor offers the available values to pick from.
  4. Add the three filters, the count condition and the cooldown. As YAML, the trigger looks like this:
- 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
  1. Replace acme/checkout-api and acme/payments with your own owner/name values, then save the trigger.

For a self-hosted Tares, GitHub must be able to reach your instance for App webhooks to arrive. A local tares up is not reachable from the internet, so 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

The whole trigger belongs to your SRE setup. See AI SRE for how triggers fit with the rest of your monitoring.

What you get

  • One firing for each merged pull request in acme/checkout-api and acme/payments, and none for other repositories.
  • No firing for pull requests that were closed without merging, because the action filter requires merged.
  • Values you pick instead of type. The console editor lists the event_type and action values for a GitHub source.
  • A trigger that survives a change of credential. A token and the App produce the same pull_request events.
  • A pattern you can reuse. To watch other repositories, change the repo list. To watch a different pull request action, change the action value. The labels you can filter on include repo, action, number, author, branch, base, state, draft, title and url.

When something else fits

  • If you also want reviews, pushes, releases or CI runs, use the GitHub App. Those events arrive only with the App, while a personal token reports commits and pull requests opened, merged or closed.
  • If you want to react to commits on a token source, filter on event_type commit instead of pull_request.
  • If you need to watch many repositories, one App source covers every repository it is installed on, so you do not add a source per repository.

Still stuck? Get help

Last updated on