Automation triggers
A trigger is a run rule for the automation. It sets three things: what starts a run, which branch the run works on, and what Air Teams does with the changes the run produces. An automation can have several triggers, and each trigger can handle changes differently. It can also have none, and then it runs only when you start it manually.
You add triggers in the Triggers section when you create an automation or edit an existing one. Click Add Trigger and select a start condition. Each trigger row then has up to three parts:
Start condition – the event or schedule that starts a run. See Start conditions.
Branch – the branch the run checks out, chosen with the checkout selector. Pull request and merge request triggers don't show this selector – they run on the request's source branch.
What to do with the changes – whether the run commits them, opens a pull request, or reports back without touching the code. See What to do with the changes.
Start conditions
The start condition is the event or schedule that starts a run. Choose one when you add the trigger.
Schedule
Use the At time trigger to run the automation at a specific time on selected days. This is useful for recurring daily or weekly routines.
Repetitive run
Use the Repeat every trigger to run the automation on a fixed interval, for example, every 2 hours.
GitHub events
Use GitHub event triggers to start automations in response to activity in a repository. They work on repositories from GitHub and from a self-hosted GitHub Enterprise Server instance.
Once the JetBrains Air app is installed for your personal or organization account, Air Teams automatically receives notifications for repositories covered by that installation. For a GitHub Enterprise Server instance, an organization administrator registers the instance in JetBrains Console and the app is installed there. Either way, there is no separate GitHub webhook setup inside the automation itself. To set up the app, see Connect repositories.
Each GitHub event trigger maps to a single GitHub action, so the automation runs only when that exact action happens, not on every change to the pull request or issue.
Add a GitHub event trigger
In the Triggers section of the automation, click Add Trigger.
Select GitHub, then the group and the event – for example, . For the available events, see the list below.
Optionally, add filters – extra conditions the event has to meet before the trigger fires. Expand the trigger row, click Add Filter, and select the filter. On , for example, add PR author to run only on one person's pull requests, or Ignore drafts to skip drafts.
Which filters are offered depends on the event, and a trigger with several of them fires only when all of them match.
GitHub events by group:
Opened – a new pull request is created. Reopening a closed pull request doesn't fire this trigger.
Moved out of draft – a draft pull request is marked ready for review.
Labeled – a label is added to the pull request. Enter the label in the Label name field. Removing a label doesn't fire this trigger. If you add several labels at once, the trigger fires once per label.
New changes – new commits are pushed to the pull request branch. This is the GitHub
synchronizeaction. It doesn't fire on comments, label changes, or edits to the title or description.Review requested – a review is requested from a user or team on the pull request.
Review received – a review is submitted on the pull request. Use the Any review selector to react only to approvals, change requests, or comments.
Merged – the pull request is merged into its target branch. Closing a pull request without merging doesn't fire this trigger.
Opened – a new issue is created.
Labeled – a label is added to an issue. Enter the label in the Label name field. Removing a label doesn't fire this trigger. If you add several labels at once, the trigger fires once per label.
Workflow events rely on GitHub Actions.
Failed – a GitHub Actions workflow run fails. Use this to investigate a failed build or prepare a recovery change.
Job failed – a single job within a GitHub Actions workflow fails. Enter a name in the Job name field to react only to a specific job.
Comments on pull requests and issues don't fire these triggers. To start an automation from a comment or another external signal, use an incoming webhook.
GitLab events
Use GitLab event triggers to start automations in response to activity in a GitLab repository. They work on repositories from GitLab.com and from a GitLab Self-Managed instance, and behave like their GitHub counterparts, named in GitLab terms.
GitLab has no equivalent of the JetBrains Air GitHub app, which sends events for every repository it's installed for. Instead, each GitLab project needs its own webhook that sends the project's events to Air Teams. You don't create it yourself: when you save an automation with a GitLab trigger, Air Teams adds the webhook to the project on your behalf, unless the project already has one.
Before you add a GitLab event trigger, make sure that:
The automation's repository is on GitLab. The Add Trigger menu offers the events of the service that hosts the repository. Your GitLab account must be connected – see Connect a VCS provider. For GitLab Self-Managed, an organization administrator also has to register the instance – see Set up organization repository access.
You have the Maintainer or Owner role in the GitLab project, which adding a webhook requires – see Roles and permissions in the GitLab documentation. You need it only for the first automation with GitLab triggers on the project. Once the project has the webhook, anyone who can edit an automation can add GitLab triggers to it.
If the webhook can't be added, the automation is saved but paused – see An automation with GitLab triggers is paused after you save it.
Add a GitLab event trigger
In the Triggers section of the automation, click Add Trigger.
Select GitLab, then the group and the event – for example, . For the available events, see the list below.
Optionally, add filters: expand the trigger row, click Add Filter, and select the filter. GitLab triggers take the same filters as GitHub ones, except the merge request author and the work item author.
Save the automation. If the GitLab project has no webhook yet, Air Teams adds it now.
GitLab events by group:
Opened – a new merge request is created.
Marked as ready – a draft merge request is marked as ready.
Labeled – a label is added to the merge request. Enter the label in the Label name field.
New changes – new commits are pushed to the merge request's source branch.
Review requested – a reviewer is added to the merge request, or a review is requested again.
Approved – someone approves the merge request. Unlike Review received on GitHub, it doesn't fire when a reviewer requests changes or leaves a comment.
Merged – the merge request is merged.
Work item events cover GitLab issues too.
Opened – a new issue or work item is created.
Labeled – a label is added to an issue or work item. Enter the label in the Label name field.
Pipeline events rely on GitLab CI/CD.
Failed – a pipeline fails.
Job failed – a single job in a pipeline fails. Enter a name in the Job name field to react only to a specific job.
Comments on merge requests and work items don't fire these triggers. To start an automation from a comment or another external signal, use an incoming webhook.
Jira events
Use Jira event triggers to start automations from activity on a Jira issue. They work once a Jira administrator has connected your Jira instance to Air Teams – see Connect Jira. Until then, a Jira trigger can't be saved.
To add one, click Add Trigger, select , and pick the event:
Issue created – an issue is created.
Issue labeled with – a label is added to an issue. Enter the label. The trigger fires when that label is added, not on later updates to an issue that already carries it.
Issue assigned to – an issue is assigned. Enter the assignee.
Issue status changed to – an issue moves to a status. Enter the status.
Issue priority changed to – an issue's priority changes. Enter the priority.
Issue resolved – an issue gets a resolution.
Issue commented – a comment is added to an issue. Optionally, enter text the comment must contain.
Jira delivers most of these as the same generic issue-updated event, so the value you enter is what tells Air Teams which change to react to. It's required for that reason – an empty one would widen the trigger to every update to the issue.
Every Jira trigger also takes an optional project key in the in project field. Leave it empty to react to issues in any project the webhook covers.
A Jira trigger can handle its changes as either Create a PR or No code changes – see What to do with the changes.
Chained automations
Use the Automation finished trigger to start an automation when a run of another automation finishes successfully. Select the automation to wait for in the Automation field. This chains automations into a multi-step workflow. The new run's agent gets the finished run's summary and links, and the name of the branch it pushed, as input. See Chained automations.
Incoming webhooks
Use the Webhook trigger to start an automation from an external system. This is useful when another service needs to notify Air Teams about an event and trigger an automation run.
After you add the trigger and save the automation, Air Teams generates:
a webhook URL in the format
.../api/v1/events/automations/<automation-id>a permanent token used to authorize requests to this webhook
Use Copy Webhook URL and Copy Token to copy these values from the trigger section.
Configure your external system to send an HTTP POST request to the webhook URL and include the token in the Authorization header as Authorization: ApiKey <token>.
The request body is optional. You can send a webhook without any payload if the automation only needs the event itself.
If you want to pass additional input to the automation task, send a JSON payload in the request body. This payload becomes part of the task context.
For example:
What to do with the changes
Tell the trigger what Air Teams does with the changes a run produces. This decides where the result lands, so you can send an automation straight to a pull request or keep it review-only. For what you can do with a run afterward, see Work with automation run results.
No code changes – the run doesn't commit or push anything. Use it for automations that analyze, triage, or report and return their result through the run output or a notification.
Push to source branch – commits and pushes the changes to the branch the run worked on: the checked-out branch, or the pull request's source branch. Use it to add commits to an existing pull request or update a branch in place.
Push to new branch – creates a new branch for the run's changes and pushes to it, without opening a pull request. You can open one later from the run.
Create a PR – pushes the changes to a new branch and opens a pull request automatically. On a GitLab repository, this option is Create an MR and opens a merge request.