Using Press Build 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 at deployment time, to allow the workflow configuration to more accurately reflect their specific usecase, without you as the developer needing to produce multiple nearly-identical iterations of your spec. Press build parameters are meant for this specific usecase. Here’s how you can use them.
Using Build Parameters in Workflows
Creating the Block Spec
When creating the block spec, you will need to make the required parts of the config
customizable. Here’s an example spec that contains a parameterized config
, and the corresponding parameter objects that describe the metadata of each parameter. We will parameterize the instanceTypeId
,storage
and watcher["user"]
fields, to allow for a slightly different processing power and storage for the test
step, and a different target for workflow success/fail events. These would be common things that different users might want to vary, obviously much more could be done here. We have also added options for the instance type parameter.
# 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
resources:
instanceTypeId: "@param:instance_type"
storage: "@param:storage"
type: standard
image:
context: "."
dockerfile: Dockerfile
version: 0.0.1
buildArguments:
API_KEY: {{ api_key }}
triggers:
- cron: "0 0 * * *"
watchers:
- user: "@param:watcher_user"
events:
success: false
fail: true
parameters:
build:
- defaultValue: 21
description: Computational power to allow for the test step
name: instance_type
options:
- title: regular
value: 21
- title: large
value: 23
required: false
title: Instance Type
type: number
- defaultValue: 10GB
description: The storage for the test step
name: storage
required: false
title: Storage
type: string
- description: Email to send workflow success/fail events to
name: watcher_user
required: true
title: Watcher User
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:
build:
instance_type: 23
storage: 20GB
watcher_user: my-email@email.com
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
The result
This will create the deployment, replacing the spec config
section’s parameterized values with the provided deployment build parameter values, like so:
config:
steps:
test:
command: echo 1
resources:
instanceTypeId: 23
storage: 20GB
type: standard
image:
context: "."
dockerfile: Dockerfile
version: 0.0.1
buildArguments:
API_KEY: {{ api_key }}
triggers:
- cron: "0 0 * * *"
watchers:
- user: my-email@email.com
events:
success: false
fail: true