*`name` - Unique name for the step. This step can be referenced by any proceeding steps in the pipeline using its name.
* One of the following:
*`base_task_project` and `base_task_name` - Project and name of the base task to clone
*`base_task_id` - ID of the base task to clone
*`cache_executed_step`– If `True`, the controller will check if an identical task with the same parameters was already executed. If it was found, its outputs will be used instead of launching a new task.
*`execution_queue` (Optional) - the queue to use for executing this specific step. If not provided, the task will be sent to the default execution queue, as defined on the class
*`parents`– Optional list of parent steps in the pipeline. The current step in the pipeline will be sent for execution only after all the parent steps have been executed successfully.
*`parameter_override` - Dictionary of parameters and values to override in the current step. See [parameter_override](#parameter_override).
*`configuration_overrides` - Dictionary of configuration objects and values to override in the current step. See [configuration_overrides](#configuration_overrides)
*`monitor_models`, `monitor_metrics`, `monitor_artifacts` - see [here](#models-artifacts-and-metrics).
See [add_step](../references/sdk/automation_controller_pipelinecontroller.md#add_step) for all arguments.
#### parameter_override
Use the `parameter_override` argument to modify the step’s parameter values. The `parameter_override` dictionary key is
the task parameter’s full path, which includes the parameter section's name and the parameter name separated by a slash
(e.g. `'General/dataset_url'`). Passing `"${}"` in the argument value allows you to reference input/output configurations
from other pipeline steps. For example: `"${<step_name>.id}"` will be converted to the Task ID of the referenced pipeline
Creating a pipeline step from a function means that when the function is called, it will be transformed into a ClearML task,
translating its arguments into parameters, and returning values into artifacts.
Function steps are added using the [`PipelineController.add_function_step`](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step)
*`name` - The pipeline step’s name. This name can be referenced in subsequent steps
*`function` - A global function to be used as a pipeline step, which will be converted into a standalone task
*`function_kwargs` (optional) - A dictionary of function arguments and default values which are translated into task
hyperparameters. If not provided, all function arguments are translated into hyperparameters.
*`function_return` - The names for storing the pipeline step’s returned objects as artifacts in its ClearML task.
*`cache_executed_step` - If `True`, the controller checks if an identical task with the same parameters was already
executed. If it was found, its outputs are used instead of launching a new task.
*`parents`– Optional list of parent steps in the pipeline. The current step in the pipeline will be sent for execution
only after all the parent steps have been executed successfully.
*`pre_execute_callback`&`post_execute_callback` - Control pipeline flow with callback functions that can be called
before and/or after a step’s execution. See [here](#pre_execute_callback--post_execute_callback).
*`monitor_models`, `monitor_metrics`, `monitor_artifacts` - see [here](#models-artifacts-and-metrics).
See [add_function_step](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step) for all
arguments.
### Important Arguments
#### pre_execute_callback & post_execute_callback
Callbacks can be utilized to control pipeline execution flow.
A `pre_execute_callback` function is called when the step is created and before it is sent for execution. This allows a
user to modify the task before launch. Use node.job to access the [ClearmlJob](../references/sdk/automation_job_clearmljob.md)
object, or node.job.task to directly access the Task object. Parameters are the configuration arguments passed to the
ClearmlJob.
If the callback returned value is False, the step is skipped and so is any step in the pipeline that relies on this step.
Notice the parameters are already parsed (e.g. `${step1.parameters.Args/param}` is replaced with relevant value).
```python
def step_created_callback(
pipeline, # type: PipelineController,
node, # type: PipelineController.Node,
parameters, # type: dict
):
pass
```
A `post_execute_callback` function is called when a step is completed. It allows you to modify the step’s status after completion.
```python
def step_completed_callback(
pipeline, # type: PipelineController,
node, # type: PipelineController.Node,
):
pass
```
#### Models, Artifacts, and Metrics
You can enable automatic logging of a step’s metrics /artifacts / models to the pipeline task using the following arguments:
*`monitor_metrics` (Optional) - Automatically log the step's reported metrics also on the pipeline Task. The expected
format is one of the following:
* List of pairs metric (title, series) to log: [(step_metric_title, step_metric_series), ]. Example: `[('test', 'accuracy'), ]`
* List of tuple pairs, to specify a different target metric to use on the pipeline Task: [((step_metric_title, step_metric_series), (target_metric_title, target_metric_series)), ].
can be specified through `execution_queue` of the [`PipelineController.add_step`](../references/sdk/automation_controller_pipelinecontroller.md#add_step)
or [`PipelineController.add_function_step`](../references/sdk/automation_controller_pipelinecontroller.md#add_function_step)
