Execute rules & constraints

Execute rules allow you to control task or runbook execution. For example, you can require executions to go through requests or re-authentication, or constrain runs to specific agents.

By default, tasks and runbooks do not require requests and allow self-approvals. You can turn on these options in the Advanced section of the task or runbook editor:

If a task is run in a session, then it also considers the request on the session (if it exists) when determining if the execute rules have been satisfied. In other words, if a session contains a task that requires requests, and that session was requested, this satisfies the request requirement for the task, and the task is executed as normal. Similarly, if the task disallows self-approvals and the session request was not self-approved, the task is executed automatically.

However, if the request on the session does not satisfy the task's execute rules, or the session was executed directly, then a request for that task will be automatically opened instead.

Configuring a runbook or task to require re-authentication will prompt the user executing a runbook or task or approving a request to authenticate again by signing in through Google or SSO. You can turn on this option in the Advanced section of the task or runbook editor, under Execute Rules.

Require re-authentication is only enabled upon request. Please email us at support@airplane.dev if you'd like access.

If you're self-hosting Airplane agents, you may want to control which agents a run can be scheduled on. For example, you might have agents with different network configurations, and a certain task must execute in a specific network.

With label constraints, runs will be scheduled only on agents with matching labels. Label constraints can be specified on both tasks and runbooks.

When executing built-ins from tasks, the built-in run will inherit the constraints of the task run that called it. Similarly, when executing tasks from runbooks or workflows, the task will inherit constraints. In the case of overlapping labels, the child run's constraints will take precedence over its inherited constraints.

Agent labels can be set with the AP_LABELS environment variable. Labels are key:value string pairs separated by spaces.

Example: AP_LABELS="aws-region:us-west-2 environment:prod"

For details on configuring agent labels for your specific environment, see Agents.