protocol.yml field reference¶
Overview¶
protocol.yml is the declarative file that defines a protocol: protocolSchema: v3 in standard YAML, replacing the deprecated protocol.json + script.js pair (see Legacy v2 format below). A protocol has no code of its own — it lists steps, each of which invokes an already-published task-script function, and can declare pipeline-facing config and author-set constants that steps and expressions read from.
protocolSchema: "v3"
name: "Example Protocol"
description: "This is just to show a basic protocol.yml file"
config:
idsFileCategory:
label: "IDS File Category"
description: "Optional File Category"
type: "string"
required: false
default: "IDS"
steps:
- id: raw-to-ids
task:
namespace: common
slug: akta-raw-to-ids
version: v3.1.6
function: akta-raw-to-ids
input:
input_file_pointer: $( workflow.inputFile )
ids_file_category: $( config.idsFileCategory )
For the $( ... ) expression language itself — contexts and functions — see Expressions.
protocolSchema¶
Required. Must be exactly the string "v3". This indicates the file uses the v3 schema; a future JSON-encoded form of this schema is possible but not currently supported.
Manifest fields¶
All of the following are top-level in protocol.yml, optional, and mirror the corresponding fields in the protocol’s manifest.json (see Repo structure):
Field |
Type |
Notes |
|---|---|---|
|
string |
Must be |
|
string |
|
|
string |
|
|
string |
The protocol’s identifier |
|
string |
Display name |
|
string |
Short description |
|
list of strings |
Deprecated in favor of |
|
list of |
See the reserved-name list in Repo structure |
ts-cli only warns, and does not fail the build, if a value here disagrees with the same field in manifest.json — keep them in sync manually.
config¶
Optional. An object mapping a config ID to a config object. Each ID must be unique so it can be referenced from steps or from an expression. Config objects cannot themselves contain expressions.
config:
numberConfig:
label: "Enter a Number"
description: "This number will be used by the task scripts"
type: number
default: 9000
secretExample:
label: "ELN Password"
description: "The password to push data to some ELN"
type: secret
config.<config_id>.label¶
Required. String. The label rendered for this config in the TDP pipeline configuration UI.
config.<config_id>.type¶
Required. One of number | string | boolean | secret | object | array. Determines how the UI renders the field and how the value is passed to the workflow. array was added in TDP v4.4.
config.<config_id>.description¶
Optional string, rendered in the pipeline configuration UI.
config.<config_id>.required¶
Optional boolean, defaults to false. Enforced both in the UI and at workflow run-time.
Important
A config with required: false and no default still produces the key at run time — it arrives at the task script as null (None in Python). Either give it a default or have the task script handle a missing value explicitly.
config.<config_id>.default¶
Optional. Must match the config’s type. Cannot contain expressions. Used when the user hasn’t set a value via the UI.
config.<config_id>.component (added in TDP v4.3.2)¶
Optional object. Requests a specific UI widget for this config. This is only a request — the UI falls back to the default input for the config’s type if the requested component isn’t implemented. As of this writing, only select is actually wired up in the TDP UI; the rest are accepted by the schema and silently ignored by the UI.
|
Shape |
Supported in UI? |
|---|---|---|
|
|
Yes |
|
|
No |
|
|
No |
|
|
No |
|
|
No |
|
|
No |
component:
type: select
options:
- label: "Option A"
value: a
config.<config_id>.schema (added in TDP v4.4.0)¶
Optional. Any valid JSON Schema Draft 2020-12 object. Requests that the pipeline configuration value be validated against this schema — but TDP does not currently enforce it. Don’t present it to an author as a working validation mechanism.
constants¶
Optional. An object mapping a constant ID to any value, so a protocol can define a value once instead of repeating it. Each ID must be unique across constants so it can be referenced from steps or other constants. Circular dependencies between constants are detected and rejected.
Constants may contain expressions, but those expressions have no steps context — nothing has run yet when constants are evaluated.
constants:
REMOTE_PORT: 8080
REMOTE_URL: "http://example.com"
VALID_VALUES:
- 80
- 443
- $( constants.REMOTE_PORT )
CONFIG_OBJECT:
url: $( constants.REMOTE_URL )
ports: $( constants.VALID_VALUES )
steps¶
Required. A list of step objects, each of which invokes a task-script function.
steps:
- id: stepOne
task:
namespace: common
slug: raw-to-ids
version: v1.0.0
function: main
input:
input_file_pointer: $( workflow.inputFile )
- task:
namespace: common
slug: push-to-eln
version: v2.1.0
function: "push-it"
input:
ids_file: $( steps.stepOne.output )
options:
timeoutInSec: $( config.pushToElnTimeout )
steps[*].id¶
Optional string. A unique identifier for the step, so later steps and expressions can address it by name instead of by list index. Always give a step an id — see the accessor-form guidance in Expressions.
steps[*].if¶
Optional boolean or expression. The step runs only when this evaluates to true; otherwise its status becomes skipped. If omitted, the step always runs.
config:
skip-chromatograms:
label: Skip step 'Extract chromatogram data using the MassLynx SDK'
description: >
Boolean. Optional. Default is `False`. If `True`, this modifies the
protocol to skip the step 'Extract chromatogram data using the MassLynx
SDK'.
type: boolean
required: false
default: false
steps:
- id: extract-chromatogram-data-from-raw-zip
if: $( not(config["skip-chromatograms"]) )
description: Extract chromatogram data using the MassLynx SDK
task:
namespace: common
slug: masslynx-windows
version: v1.0.3
function: main
input:
input_file_pointer: $( workflow.inputFile )
Note the bracket accessor config["skip-chromatograms"] — required because the config ID contains a hyphen. config is always an ID-keyed mapping, never a list.
steps[*].continueOnError¶
Optional boolean or expression. If the step’s task fails and this evaluates to true, the protocol continues running; otherwise the whole protocol fails when this step fails. Useful for running cleanup steps after a failure.
steps[*].description¶
Optional string, shown on the TDP UI.
steps[*].task¶
Required object with four required sub-fields:
Field |
Notes |
|---|---|
|
e.g. |
|
e.g. |
|
e.g. |
|
Must match one of the |
steps[*].input¶
Optional, any type. Evaluated and passed directly as the task-script function’s input argument — its keys are exactly the parameter names the task script’s Python code reads. Can contain expressions.
steps[*].options¶
Optional object of runner overrides:
Field |
Notes |
|---|---|
|
Overridable in the pipeline configuration UI |
|
Step is marked failed if this is exceeded |
|
Runs the task on a specific Windows EC2 AMI (string or expression); the AMI must exist in the same AWS region as the target TDP |
|
Boolean or expression |
successWhen (added TDP v4.3.0)¶
Optional boolean or expression. Overrides the default rule that a workflow succeeds only if every step succeeds.
successWhen: $( or(steps.stepOne.isSuccess, steps.stepTwo.isSuccess) )
onFailed (added TDP v4.3.0)¶
Optional, any type. Overrides the output value of a failed workflow, for logging. Defaults to null when successWhen is used.
onFailed: $( coalesce(steps.stepOne.error, steps.stepTwo.error) )
constraints (added TDP v4.3.2–v4.4.0 — confirm against your target TDP version)¶
constraints:
trigger:
type: ["file", "scheduled"] # or a single string, e.g. type: "scheduled"
The only valid constraints.trigger.type values are "file" and "scheduled", singly or as a list — this is verified directly against the shipped ts_protocol_virtual_machine compiler schema (z.enum(["file", "scheduled"])). If constraints is omitted, the trigger type defaults to ["file"] — a protocol without scheduled in its trigger types won’t appear in the pipeline editor’s protocol picker when a SCHEDULED trigger is selected.
Note
constraints is stripped out of the protocol.yml stored in S3 by the artifact builder and copied into build-record.json instead, for backward compatibility with older TDP versions (the schema protocol.yml is validated against has always been strict, so an older deployment would otherwise fail on an unrecognized field). What an author writes in constraints and what ships in the published protocol.yml therefore differ — this is expected, not a bug.
Legacy v2 format (recognition only)¶
Deprecated November 2023 — do not author new protocols this way, but recognize it when maintaining an older repo. A v2 protocol is protocol.json (a declarative step list, no $( ... ) expression language) plus an imperative script.js that calls workflow.runTask directly. Its config is a list of {slug, name, type, required} objects — unlike v3’s ID-keyed mapping, and not a shape to carry over into a new v3 file.