Automations & Triggers
Relevant source files
The following files were used as context for generating this wiki page:
Automations & Triggers allow Rebase to perform background tasks autonomously based on schedules or external events. The system manages persisted automation definitions, tracks run history, and coordinates with external providers like GitHub and Linear to trigger agent sessions.
Users configure automations with specific prompts, model settings, and trigger conditions. When a trigger condition is met, the system creates an AutomationRun and launches a corresponding session to execute the requested work.
System Architecture
The automation system consists of a TypeScript frontend for UI and state management, and a Rust backend (rebase-core) for persistence and scheduling.
The diagram shows the flow from user configuration in the UI to persistence and execution in the Rust backend.
Sources: src/features/automations/ui/AutomationsView.tsx, crates/rebase-core/src/automations.rs:434-453
Data Models
Automation Entity
An Automation defines the task to be performed and the conditions under which it should run.
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier for the automation. |
name | string | User-defined name for the automation. |
prompt | string | The instructions provided to the agent during a run. |
enabled | boolean | Whether the automation is active and polling for triggers. |
triggerKind | string | The primary trigger type (e.g., "time", "github"). |
nextRunAt | i64 | Timestamp (ms) of the next scheduled run. |
workspaceMode | string | Environment for the run: "current" or "worktree". |
Sources: crates/rebase-core/src/automations.rs:44-77, src/features/automations/model/automations.ts:32-61
Automation Triggers
Triggers define the specific events or times that initiate an automation. Rebase supports multiple triggers per automation.
| Trigger Kind | Event Types |
|---|---|
| time | hourly, daily, weekdays, weekly |
| github | draft_opened, pull_request_opened, issue_opened |
| linear | issue_created |
| gitlab | merge_request_opened, issue_opened |
| azuredevops | pull_request_appeared, work_item_appeared |
Sources: src/features/automations/ui/AutomationsView.tsx:1200-1230, crates/rebase-core/src/automations.rs:114-135
Scheduling Logic
The system calculates the nextRunAt timestamp based on AutomationScheduleKind. The Rust service provides calendar arithmetic that accounts for local time zones and daylight-saving changes.
The sequence diagram illustrates how the backend service determines the next execution time for a time-based trigger.
Sources: crates/rebase-core/src/automations.rs:645-690, src/features/automations/model/automations.ts:251-285
Event Claiming & Deduplication
To prevent duplicate runs for the same external event (e.g., the same GitHub PR), the system uses an automation_event_claims table. The backend ledger ensures that polling or overlapping refreshes do not re-run a previously claimed item.
- Identity Generation: The system generates a unique
event_keyfrom the provider, kind, and resource ID (e.g.,github:pr:acme/app:12). - Atomicity:
claim_eventuses a SQLINSERT OR IGNOREstatement. If the insertion fails (key exists), the claim is denied. - Scope Validation: The system verifies that the event matches the automation's project path (
cwd) and repository filters before attempting a claim.
Sources: crates/rebase-core/src/automations.rs:569-605, crates/rebase-core/src/automations.rs:807-840, src/features/automations/model/automationEvents.test.ts:40-52
Templates & Categories
Rebase provides pre-defined templates to help users bootstrap common workflows. These templates are grouped into categories like "Code Review", "Security", and "Incidents".
| Category | Example Template | Trigger |
|---|---|---|
| Code Review | Find critical bugs | Weekdays at 09:00 |
| Security | Scan for vulnerabilities | Weekly (Monday) |
| Incidents | Triage GitHub issues | GitHub: issue_opened |
| Environment | Environment doctor | Weekly (Monday) |
Sources: src/features/automations/model/automationTemplates.ts:32-150
Execution Recovery
The recover function handles runs interrupted by application stops or crashes.
- Pending Runs: Retained and returned for dispatch.
- Running Runs: Moved to a
cancelledstatus with an error indicating an interruption. - Prompt Availability: Event-based runs that lose their associated prompt in memory are marked as
failed.
Sources: crates/rebase-core/src/automations.rs:498-545
Summary
The Automations & Triggers system provides a robust framework for autonomous agent operations. By combining local SQLite persistence, time-zone-aware scheduling, and external event deduplication, it ensures that agents perform consistently and correctly without manual intervention. Users manage these workflows through a specialized UI that supports template-based creation and detailed run history tracking.