Triggers

​

What a trigger does

A trigger decides when a workflow fires and which repositories it fires against. Triggers are optional: every workflow can always be run by hand, so add a trigger only when you want Console to fire it without you. Manage triggers in the Triggers section of the workflow editor. Click Add trigger, pick a type, and choose its repositories.

​

Manual runs

Every workflow supports manual runs. There’s nothing to configure and nothing appears in the Triggers section — it’s always available. With a manual run you choose the repositories at the moment you fire it, and you can optionally pin a specific branch, tag, or commit. See Running a workflow.

​

Pull request triggers

Select On pull requests to fire the workflow automatically against pull and merge requests.

​

When it fires

Despite the name, this trigger fires on more than just opening a pull request. It fires when a pull request is:

• Opened
• Reopened
• Updated with new commits

An update supersedes the earlier run — Console cancels the in-flight run and starts a fresh one at the new head commit, so a merge gate re-evaluates against the code that’s actually there now, instead of staying stuck on a verdict for a commit nobody is merging.

​

Repositories

Choose one or more connected repositories to watch. A trigger with no repositories won’t save. Pull-request runs always clone the pull request’s head — the proposed code, not the base branch. You cannot pin a branch or commit on a pull request trigger, because the head is what’s under review.

​

Base branch filter

By default the workflow fires on pull requests targeting any branch. Add one or more base branches to narrow it to pull requests aimed at those branches specifically — a common choice is to gate only what’s merging into main. Matching is exact. A pull request whose base branch isn’t in your list is skipped before Console provisions anything, so filtered-out pull requests cost you nothing.

​

Draft pull requests

Draft pull requests are always skipped. Work in progress doesn’t warrant a run, and the workflow will fire once the pull request is marked ready.

​

Requirements

Pull request triggers depend on Console receiving events from your source control provider, which means the repository must be connected and the Console GitHub App installed for it. See Installation.

​

One run per repository

A trigger that names three repositories produces three runs when it fires — one per repository, each in its own sandbox. Runs from the same firing are grouped, so you can see them together in the run history, but they succeed or fail independently.

​

Superseding in-flight runs

When a workflow fires again from the same trigger, Console cancels any of that trigger’s runs that are still pending or running before starting the new ones. This keeps a rapidly-updated pull request from stacking up parallel sandboxes for commits that are already stale, and it means the verdict on a pull request always reflects its latest commit. It applies to manual runs too: firing a workflow manually while an earlier manual run is still going replaces it.

​

Scheduled triggers

Select Scheduled to fire the workflow at fixed times — nightly, every weekday morning, on the first of the month — with nobody in the loop. A scheduled trigger is a cron expression, a timezone, and the repositories to run against.

​

Writing the schedule

The schedule is a standard five-field cron expression, read left to right as minute hour day-of-month month day-of-week: In every field but the minute you can combine values the usual ways: Names are case-insensitive, so mon-fri and MON-FRI are the same. Some more examples: The editor previews the next few times a schedule will fire as you type, on the schedule’s own clock, and hovering the schedule on a saved trigger shows the same preview.

​

Timezone

Every schedule runs on the wall clock of the timezone you pick, which defaults to your own. 0 9 * * 1-5 in America/Denver fires at 09:00 Denver time year-round and follows its daylight-saving changes; pick UTC for a schedule that must not shift. Timezones are the standard IANA names (Europe/Berlin, Asia/Tokyo, UTC).

​

Repositories

For a workflow scoped to a project, choose one or more connected repositories, exactly as for a pull-request trigger. A trigger with no repositories won’t save. Each repository is cloned at its own default branch; a scheduled trigger cannot pin a branch or commit. For a workflow scoped to the whole organization, there is nothing to choose: the run covers the organization.

​

Overlapping runs

Scheduled triggers do not supersede their own runs. If a repository’s previous scheduled run is still pending or running when the next occurrence comes due, that occurrence is skipped for that repository and nothing is cancelled; the other repositories on the trigger fire as normal. A workflow that takes longer than the gap between occurrences therefore runs back-to-back rather than piling up sandboxes.

​

Stopping and attribution

Deleting the trigger — or the workflow — ends the schedule. A trigger that is turned off fires nothing, and no missed occurrences are made up when it is turned back on. Runs from a scheduled trigger are attributed to the person who created the trigger, and the run history labels them as scheduled with the time they were due.

​

Limits

• At most once per hour. The minute field must be a single number — 15 * * * * fires every hour at :15, while */15 * * * * and 0,30 * * * * are rejected.
• One day field at a time. Restrict the day of month or the day of week, not both. The other must be *.
• No extended syntax. L, W, #, ?, a sixth (seconds) field and shorthands such as @daily are not supported.
• Up to 25 scheduled triggers per organization, across all workflows.

The editor rejects an expression that breaks one of these rules and says which.

​

Next steps