t into the step

print(0.01)

trainer(gamma=gamma)Important note, in the above case, the value of the step would be the one defined in the steps key (i.e. 0.001). So the YAML config always takes precedence over pipeline parameters that are passed down to steps in code. Read this section for more details.

Normally, parameters defined at the pipeline level are used in multiple steps, and then no step-level configuration is defined.

Note that parameters are different from artifacts. Parameters are JSON-serializable values that are passed in the runtime configuration of a pipeline. Artifacts are inputs and outputs of a step, and need not always be JSON-serializable (materializers handle their persistence in the artifact store).

Setting the run_name

To change the name for a run, pass run_name as a parameter. This can be a dynamic value as well.

run_name: <INSERT_RUN_NAME_HERE>

You will not be able to run with the same run_name twice. Do not set this statically when running on a schedule. Try to include some auto-incrementation or timestamp to the name.

Stack Component Runtime settings

Settings are special runtime configurations of a pipeline or a step that require a dedicated section. In short, they define a bunch of execution configuration such as Docker building and resource settings.

Docker Settings

Docker Settings can be passed in directly as objects, or a dictionary representation of the object. For example, the Docker configuration can be set in configuration files as follows:

settings:

docker:

requirements:

pandas

Find a complete list of all Docker Settings here. To learn more about pipeline containerization consult our documentation on this here.

Resource Settings

Some stacks allow setting the resource settings using these settings.

resources:

cpu_count: 2

gpu_count: 1

memory: "4Gb"

Note that this may not work for all types of stack components. To learn which components support this, please refer to the specific orchestrator docs.

failure_hook_source and success_hook_source