Reference remote tasks and resources from the local studio.
By default, any task referenced by a view or another task must be registered when the studio starts up. Additionally, any resource or config variable utilized by a task or built-in must also exist locally in the dev config file.
However, there are scenarios where you may not want to use local tasks or resources. For example, you may want to:
- Execute a task or built-in against a real database.
- More quickly test changes by not needing to boot local versions of your resources.
- Locally test a task or view without having to configure the tasks they rely on.
In these cases, you can use a fallback environment to indicate that you'd like to execute a task or reference a resource in a remote environment.
Local tasks, resources, and configs will always take precedence over remote ones, even if a fallback environment has been set.
Specifying a fallback environment
To use a fallback environment, specify an
--envflag to the
bashCopied1$ airplane dev --env production2Discovering tasks and and views...registered 2 tasks and 1 view.34Your fallback environment is set to Production.5- Any task not registered locally will execute in Production.6- Any resource or config not declared in your dev config will be loaded from Production.78Started studio session at https://app.airplane.dev/studio?host=http://localhost:4000&__env=prod (^C to quit)9Press ENTER to open the studio in the browser.
You may also set your fallback environment to your default remote environment by passing
--envflag. For example, if your default environment is
production, the following commands would be equivalent:
bashCopied1airplane dev --env production
bashCopied1airplane dev --env default
Tasks can be referenced from both Views and other tasks. If a fallback environment has been specified and a task has not been registered with the studio locally, then that task will be executed remotely in the fallback environment.
Any tasks executed remotely will have an indicator next to them:
Note that local tasks can execute remote tasks, but not the other way around. Once a task has been executed remotely, any other tasks it executes will also be executed remotely even if those tasks have been registered locally.
For example, consider the following scenario:
- A fallback environment
productionhas been declared.
Care registered locally.
Care deployed remotely in
Aruns, the studio will detect that
Bis not registered locally, and attempt to execute
Cwill also execute remotely, even though it was registered locally with the studio, since remote executions are not aware of any local tasks.
If executing a built-in or a task that uses a resource (e.g. a SQL or REST task), by default the studio will look for those resource credentials in the dev config file. If a fallback environment is specified, the studio will look in that remote environment if it doesn't find the given resource in the dev config file.
Remote resources will be shown alongside local resources in the resource tab of the studio:
Any built-ins that have been executed remotely will have an indicator, similar to remote tasks:
Remote config variables
If executing a task that uses config variables, the studio will look for those configs variables in the dev config file. If a fallback environment is specified, the studio will look in that remote environment if it doesn't find the given config variable in the dev config file.
Remote config variables will be shown alongside local config variables in the config variables tab of the studio: