Using Press Runtime Parameters

Let’s say you are creating a workflow block, and want to keep a couple of parameters configurable - values that can be changed by business users, or any one else from the Library section of the platform. Press runtime parameters are meant for this specific usecase. Here’s how you can use it.

Using Parameters in Workflows

The very first question that we need answer is how to write the code for the workflow so that it fetches and uses the parameters. For the following example let’s consider that the workflow expects two paramters - n_days and agg_type.

In the workflow’s code, you need to get the values of the parameters so that you can use them in your script. To do so, you can use the peak-sdk’s get_parameters function.
The function uses the PRESS_DEPLOYMENT_ID environment variable to get the values of the parameters. This environment variable is automatically injected in workflows when they are deployed using Press. So, you can just add the following statement to your Python script
```
from peak.press import blocks

client: blocks.Block = blocks.get_client()

parameters = client.get_parameters()
```
But we won’t have a Press Deployment ID when we are testing the workflow locally, or when we deploy it without the Press. So, how do we test out the workflow?
- Turns out it is quite easy, the get_parameters function has an optional argument called fallback_params_file which can help in this. To use it, create a YAML file and add in all the parameters that the workflow needs to it. Example:
```
n_days: 10
agg_type: sum
```
- Then, pass in the path to this file to the fallback_params_file parameter. Now, whenever the Press Deployment ID isn’t available, the data from the file will automatically be returned by the get_parameters function. And thus the workflow can run absolutely fine.
```
from peak.press import blocks

client: blocks.Block = blocks.get_client()

parameters = client.get_parameters(fallback_params_file="fallback.yml")
```

Deploying the Workflow

Once you have the workflow ready and are good to deploy it, create the block spec and deploy it.

Creating the Block Spec

While creating the block spec, remember to pass in the required parameters to it. Here’s an example spec that contains parameters. Continuing with the workflow defined above, we are defining two parameters in the workflow.

Since we are using peak-sdk in the workflow script, remember to pass API_KEY to the workflow or the image as well. We are adding that to the image as a build argument in the following example.

# block_spec.yaml.j2

body:
    version: 1
    kind: workflow
    metadata:
        name: workflow-block
        title: Workflow Block
        summary: Workflow Block
        description: Creating a new workflow block spec
        descriptionContentType: text/markdown
        imageUrl: https://my-block-pics.com/image-0.jpg
        tags:
            - name: CLI
    release:
        version: 1.0.0
        notes: This is the original release
    config:
        steps:
            test:
                command: echo 1
                type: standard
                image:
                    context: "."
                    dockerfile: Dockerfile
                    version: 0.0.1
                    buildArguments:
                        API_KEY: { { api_key } }
        triggers:
            - cron: "0 0 * * *"
        watchers:
            - user: abc@peak.ai
              events:
                  success: false
                  fail: true
parameters:
    run:
        - defaultValue: 5
          description: Number of days to parse the data for
          name: n_days
          required: true
          title: Number of Days
          type: string
        - defaultValue: SUM
          description: The aggregation mechanism to use
          name: agg_type
          required: false
          title: Aggregation Type
          type: string
artifact:
    path: "."
    ignore_files:
        - ".gitignore"
        - ".dockerignore"
featured: true
scope: shared
tenants:
    - tenant1
    - tenant2

Create the spec using the following statement

peak blocks specs create path/to/block_spec.yaml.j2 -p API_KEY=<API_KEY>

Deploying the Spec

With the Block Spec ready, we can now create the deployment for the same. To create a deployment, we first need to create a config file for the same

# block_deployment.yaml.j2

body:
    metadata:
        name: workflow-block-deployment
        title: Workflow Block Deployment
        summary: Workflow Block Deployment
        description: Creating a new workflow block deployment
        descriptionContentType: text/markdown
        imageUrl: https://my-block-pics.com/image-0.jpg
        tags:
            - name: CLI
    parameters:
        run:
            agg_type: "SUM"
            n_days: 10
    revision:
        notes: This is the initial revision
    spec:
        id: 0bddb4c6-40c5-45c3-b477-fceb2c051609
        release:
            version: 1.0.0

We can then create the deployment using the following statement

peak blocks deployments create path/to/block_deployment.yaml.j2

Updating the Parameters

Once we have the deployment created, we will have a running workflow that uses the runtime parameters. Users might want to update the values of the paramters. That can very easily be done either from the platform or using SDK/CLI.

For using CLI to update the parameters, create a YAML containing the parameters

# block_deployment_parameters.yaml.j2

body:
    agg_type: "AVG"
    n_days: 20

And run the following command

peak blocks deployments patch-parameters < deployment_id > block_deployment_parameters.yaml.j2