Task definition reference

Unique identifier for the parameter. This is the identifier you'll use to interpolate parameters into arguments, pass them when calling from the CLI, etc.

User-facing name for the parameter.

The type of the parameter. See Parameter types for more information.

User-facing description of the parameter.

Whether the parameter is required.

The default value of the parameter. The type depends on the type of the parameter.

Constrains the value of parameter to a list of options.

The type depends on the type of the parameter.

You can optionally add a label to each option. Labels are shown to the user instead of the value. To add a label, the option should be an object with fields label and value.

Example:

yaml
Copied
1
options:
2
- Alfred Pennyworth
3
- Bruce Wayne
4
- label: BW
5
  value: Bruce Wayne

For more information, see Select options.

Allows you to more dynamically control what values are permitted. For more information, see Regular expressions.

Cron string of the schedule. To see acceptable formats, see Cron syntax.

Name of the schedule.

Description of the schedule.

Map of param slugs and values to pass to the task on each run.

The path to the .ts or .js file containing the logic for this task. This can be absolute or relative to the location of the definition file.

Examples:

yaml
Copied
1
entrypoint: my_folder/my_task.ts

The Node.js version the task will be transpiled to.

Environment variables that will be passed into the task.

Environment variables can be entered directly ("from value"), or you can reference Config variables ("from config variable"). Use config variables for secrets and/or values you want to share across multiple tasks.

Example:

yaml
Copied
1
envVars:
2
  # From value
3
  NODE_ENV:
4
    value: production
5
  # From config variable
6
  MY_SECRET:
7
    config: MY_SECRET_CONFIG_VAR

The path to the .py file containing the logic for this task. This can be absolute or relative to the location of the definition file.

Examples:

yaml
Copied
1
entrypoint: my_folder/my_task.py

Environment variables that will be passed into the task.

Environment variables can be entered directly ("from value"), or you can reference Config variables ("from config variable"). Use config variables for secrets and/or values you want to share across multiple tasks.

Example:

yaml
Copied
1
envVars:
2
  # From value
3
  API_ENDPOINT:
4
    value: api.myco.dev/
5
  # From config variable
6
  MY_SECRET:
7
    config: MY_SECRET_CONFIG_VAR

The name of an SQL resource. If you don't have an existing resource, visit the Resources settings page to add a new resource.

Example:

yaml
Copied
1
resource: Prod DB

The path to the .sql file containing the SQL query. This can be absolute or relative to the location of the definition file.

Examples:

yaml
Copied
1
entrypoint: my_folder/my_task.sql

Query arguments that will be passed into the SQL query and referenced as :queryArgName.

Query arguments can either be hardcoded values or reference parameters as {{params.slug}}.

Example:

yaml
Copied
1
queryArgs:
2
  name: John
3
  # From parameter
4
  id: "{{params.user_id}}"

These can be used in your SQL script:

sql
Copied
1
SELECT * FROM users WHERE name = :name AND id = :id;

Specify the kind of transaction to use, or none for no transaction. The "auto" value here lets Airplane decide.

Example:

yaml
Copied
1
transactionMode: none

The configs attached to this task. See Config variables for more details on how to use config variables in your task.

Example:

yaml
Copied
1
configs:
2
- DEFAULT_SQL_PAGE_SIZE

The path to the .sh file containing the shell script. This can be absolute or relative to the location of the definition file.

Examples:

yaml
Copied
1
entrypoint: my_folder/my_task.sh

Environment variables that will be passed into the task.

Environment variables can be entered directly ("from value"), or you can reference Config variables ("from config variable"). Use config variables for secrets and/or values you want to share across multiple tasks.

Example:

yaml
Copied
1
envVars:
2
  # From value
3
  ENV:
4
    value: production
5
  # From config variable
6
  MY_SECRET:
7
    config: MY_SECRET_CONFIG_VAR

The name of a REST API resource. If you don't have an existing resource, visit the Resources settings page to add a new resource.

The HTTP method to use.

The path to request. Your REST resource may specify a path prefix as part of its base URL, in which case this path is joined to it. Airplane recommends that this start with a leading slash.

A key value map from param name to value.

Example:

yaml
Copied
1
page: 3
2
name: "{{params.user_name}}"

The type of body that this request should send.

The body of the request for a request of method POST, PUT or PATCH. This field is required when bodytype is json or raw.

Example:

yaml
Copied
1
bodyType: json
2
body:
3
  name: John
4
  email: "{{params.user_email}}"

The form data of the request for a request of method POST, PUT or PATCH. This field is required when bodytype is form-data or x-www-form-urlencoded.

Example:

yaml
Copied
1
bodyType: form-data
2
formData:
3
  name: John
4
  email: "{{params.user_email}}"

The configs attached to this task. See Config variables for more details on how to use config variables in your task.

Example:

yaml
Copied
1
configs:
2
- API_KEY

The name of the image to use.

The Docker command to run.

A Docker entrypoint to override the default image entrypoint. If left unset, Airplane will use the default entrypoint of the image (if any).

Example:

yaml
Copied
1
entrypoint: bash