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.
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.
Defining Markdown Content in App and Block Creation
In the CLI, you can define markdown content for the description, release notes, and revision notes of the app or block specification. Use the -d or --desc-file flag to upload the content of a markdown or text file into the description of the spec or deployment. Similarly, use -n or --release-notes-file to upload the content of a markdown or text file into the release notes of the app or block specification. The -n or --revision-notes-file flag can be used to upload the content of a markdown or text file into the revision notes of the app or block deployment.
Consider the following markdown file:
# 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 markdown file is created, you can attach it to your CLI command like this:
peak blocks specs create block_spec.yaml -v params.yaml --d /path/to/file/description.md
This command will upload the content of the description.md file into the description field of the block specification. Similarly, you can use the –release-notes and –revision-notes flags to upload markdown content into the respective fields.
Note that this will overwrite description, release notes, and revision notes present in the YAML file.
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>