Task execution

Studio supports executing tasks so you can quickly iterate and test changes before deploying them. Execution is supported in both cloud and local workspaces, with some minor differences outlined below. Task execution in cloud workspaces occurs remotely while execution in local workspaces occurs on your local machine.

Executing a task in a cloud workspace is similar to executing a deployed task. However, unlike with a deployed task, you can execute tasks with pending changes in Studio, and a run will get created with those changes reflected. When a task is executed, it will run in your active environment. Similar to deployed tasks, these runs can be scheduled on self-hosted agents.

To execute a task, select it from the Explorer tab, fill in any relevant parameters, and click Execute:

This will create a Run and you'll be redirected to it in Studio:

To execute the task in a different environment, change your active environment with the environment switcher in the Studio header.

When you are finished editing your task, click Create or Update to deploy the task.

Runs that are created in a cloud workspace are scoped to the user who created them, meaning that if you and another developer are iterating on and executing the same task, your runs won't show up in each other's Studio sessions. These runs also don't show up on the main task page; however, all cloud workspace runs do show up in the activity logs.

In some cases, you may want to disallow execution of remote tasks from Studio within a specific environment.

To do so, toggle off the Allow remote execution from Studio setting in the Environments page:

Unlike cloud workspaces, local workspace tasks are executed on your local machine.

You can locate the task you want to execute either through the Explorer tab (as shown above) or by using the File explorer tab and finding the task under the file it's defined in:

If your task requires config variables or resource configuration, you can configure these locally. You can optionally enable fallback to allow the task to access resources and config variables defined in your active environment.

If you are developing a local task that executes another task, the task being called should be registered locally with Studio. To execute a remote task when no local task is present, see the docs on enabling fallback.

When you execute a task locally from Studio, the run's environment variables will be populated with AIRPLANE_ENV_ID and AIRPLANE_ENV_SLUG, both of which will be set to studio. This can be useful for having different behavior in your code depending on if the task is running locally or not. For more information, see the runtime environment variables docs.

Tasks can have execute rules that disable execution in certain cases, specifically require requests and restrict callers. To allow developers to test those tasks, neither restriction is applied when directly executing tasks from Studio: