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’sget_parametersfunction.The function uses the
PRESS_DEPLOYMENT_IDenvironment variable to get the values of the parameters. This environment variable is automatically injected in blocks when they are deployed using Press. So, you can just add the following statement to your Python scriptfrom 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_parametersfunction has an optional argument calledfallback_params_filewhich 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_fileparameter. Now, whenever the Press Deployment ID isn’t available, the data from the file will automatically be returned by theget_parametersfunction. 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-sdkin the workflow script, remember to passAPI_KEYto 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
- description: Specify database configuration
name: database
properties:
- name: db_host
required: true
title: Database Host
type: string
- name: db_port
required: true
title: Database Port
type: number
- name: db_credentials
properties:
- name: username
required: true
title: Username
type: string
- name: password
required: true
title: Password
type: string
required: true
title: Database Credentials
type: object
required: false
title: Database Configuration
type: object
- description: Specify attributes for the charts
name: chart_attributes
title: Chart Attributes
type: object_array
properties:
- name: chart_name
required: true
title: Chart Name
type: string
- name: chart_type
required: true
title: Chart Type
type: string
- name: chart_data
required: true
title: Chart Data
type: string_array
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
database:
db_host: "localhost"
db_port: 5432
db_credentials:
username: "admin"
password: "admin" ## pragma: allowlist secret
chart_attributes:
- chart_name: "chart1"
chart_type: "line"
chart_data:
- "data1"
- "data2"
- chart_name: "chart2"
chart_type: "bar"
chart_data:
- "data3"
- "data4"
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