Using Apps and Blocks
To create apps and blocks via the Command Line Interface (CLI), we have to define a YAML file. This YAML file includes the payload, metadata, and configuration of the app or block. By utilizing jinja syntax, we have the ability to pass parameter value as {{value}}, with the actual value being specified in a separate YAML file.
Defining CLI Parameters in App and Block Creation
While creating apps or blocks, we can define cli parameters in a separate file and then use them in the actual yaml file. We can refer the parameters by enclosing the parameter names in {{ }} and specifying the file path after the -v flag in the command. We can also add parameters by adding the desired key-value pair after the -p flag. If we specify both -v and -p, the parameters defined on the command line will overwrite the parameters defined in the file.
In the cli the flag -d or --desc-file can be used to upload a markdown or text file’s content into the description of the spec or deployment. Note that in doing this, it would replace the description in your spec/deployment yaml file. Example of what a descriptive workflow may look like using markdown format:
// description.md
# Description,
**This is where you write a detailed overview of what your block/app does**
See [here](https://www.markdownguide.org/basic-syntax/) for documentation on writing markdown files for more helpful syntax.
When your file is created you can attach it to your cli:
peak blocks specs create block_spec.yaml -v params.yaml --d /path/to/file/description.md
Consider the following parameters file:
# params.yaml
git_token: "random_git_token"
npm_token: "random_npm_token"
Consider the simple spec file where we want to use the parameters defined in the above file:
# block_spec.yaml
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:
git_token: {{ git_token }}
npm_token: {{ npm_token }}
triggers:
- cron: "0 0 * * *"
We can now create the spec by running the following command:
peak blocks specs create block_spec.yaml -v params.yaml
We can also add parameters by adding the desired key-value pair after the -p flag. If we specify both -v and -p, the parameters defined on the command line will overwrite the parameters defined in the file.
peak blocks specs create block_spec.yaml -p git_token=test_git_token -p npm_token=test_npm_token
Similar approach can be used for creating other resources as well.
Creating Resource Dependencies with Artifacts
If we want to create a resource which is dependent on an Image (such as Block Spec) but we don’t want it to be source directly from the source code repository, then we will need to pack all the files we might need to build the image and pack them into an zip archive which is called Artifact.
More information for Artifact can be found in Artifact and Compression Doc.
Executing the resources of an app or block deployment
When creating an app or block spec or spec-release, we can specify whether the resources should be run or executed once the block or app is fully deployed. If autoRunOnDeploy is set to True, the resource will be executed upon full deployment of the block or app.
More information on this can be found in the dedicated sections of the app and block specs.
We can execute the above resources manually as well. But make sure the app or block is fully deployed before triggering the resources.
To do this, we can use the following command:
peak deployments execute-resources <deployment_id>