Execute tasks in a cloud or local workspace.
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
Explorertab, fill in any relevant parameters, and click
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
Updateto 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.
In order to execute cloud workspace tasks in Studio, users must have either the
Adminteam role or the
Task Admintask role.
To do so, toggle off the
Allow remote execution from Studiosetting 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
Explorertab (as shown above) or by using the
File explorertab 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.
Distinguishing Studio runs
Distinguishing Studio runs
When you execute a task locally from Studio, the run's environment variables will be populated with
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: