Creating an automation
Define the project, the request, the agent and the time — and choose carefully what runs on its own.
Before you start
- A project in the app, with the repository the routine will use.
- The agent that will execute, installed and authenticated.
- Clarity about what the routine should do and how often. A vague request running hourly generates an hour of vague work per hour.
The form
- Open Automations and use Create automation.
- Give it a Name — that is how you will recognize it in the list.
- Write what it asks for: the text the agent receives on each execution, in the language you would write to a person. There are ready-made templates to start from something known.
- Choose the agent that executes.
- Define the schedule.
- Adjust what you need — target, precheck, session, timezone — and save.
The schedule
The field accepts different forms, from the simplest to the most precise:
| Form | Example | When to use |
|---|---|---|
| Presets | hourly, daily, on weekdays, weekly | It is what you want in almost every case |
| 5-field cron | 0 9 * * 1-5 |
When you need a specific time |
| RRULE | recurrence string | When the rule does not fit in a cron |
The timezone is also configurable. It is worth checking: a time “at 9” in the wrong timezone runs at the wrong time.
Where the routine works
The routine needs to know where to run, and that changes what it leaves behind:
- In an existing workspace — the work happens in that folder, with what is already there.
- Creating a worktree per execution — each run is born in a new checkout. This isolates the runs from each other, and consumes resources every time: disk for the worktree, time to prepare the environment. Use it when independent runs are the point.
- In a specific host or host configuration — to run on the right machine, not on yours.
- With a source context — when the task’s data should come from a specific host or account.
If you do not provide the repository, the command uses the Elyra worktree corresponding to the folder it was called from, when it can resolve one.
Session between runs
- Reuse the session — the following runs are sent to that automation’s live session, when it still exists. It makes sense for work that has continuity (a review that evolves).
- New session — each run starts clean. It makes sense for independent work, and it is the most predictable: nothing from one run contaminates the next.
Reuse only applies to automations of an existing workspace.
Precheck: the gate before the run
The precheck is a limited command that runs before the execution:
- Exits with 0 → the run happens.
- Any other exit → the run is recorded as skipped, and nothing else happens.
It is how a routine avoids spending work when there is nothing to do. An example of the shape: a command that lists the open pull requests and fails when there is none. The precheck’s time ceiling is configurable — without it, a command that hangs hangs the routine.
Pausing after creating
If you want the routine ready but not running, create it and then pause it. The state is kept and nothing executes until you resume.
Scope and limits
- The routine runs without you watching. Before leaving one enabled, confirm what the agent can do in that project: it acts with the permissions it has.
- The precheck decides, it does not fix. It skips the run; it does not repair the environment.
- Creating a worktree per execution has a recurring cost. At a short interval, that turns into disk and time.