Migrating to Peak SDK new CLI

This migration guide will assist in transitioning from the Old Peak CLI to the New CLI in Peak SDK. The New Peak CLI is an improved version of the old CLI, offering enhanced features and better performance. Before proceeding with the migration, please familiarize yourself with the Documentation.

Template Parameters

In old CLI, we used to pass parameters as arguments to the command but now template parameters can be passed in two ways:

Using YAML File: Create a YAML file containing parameters and their values, then use the -v or --params-file flag with the command and provide the path to the YAML file.

Example YAML file (params.yaml):
```
# params.yaml

param1: value1
param2: value2
```
Example command to use the YAML file with the workflow:
```
peak workflows create path/to/body.yaml -v path/to/params.yaml
```
Passing Parameters Directly: You can pass the parameters directly through the command line using the -p or –params flag, followed by the parameter name and value.

Example:
```
peak workflows create path/to/body.yaml -p param1=value1 -p param2=value2
```

For more information on parameters, refer to CLI Usage.

Changes in Image resource

When creating an image with the New Peak CLI, we will now need to create a yaml file which containing the request body and need to pass this file path to the command, instead of passing request details directly as arguments. More information about the request structure can be found here.
The peak images update command is now replaced by peak images update-version. Images now support versioning, and we can update those versions if they are not built successfully. Otherwise, we can create a new version.

Changes in Workflow resource

To create or update a new workflow with the New Peak CLI, the request details should be inside the body key.
To run or trigger a workflow, we can now use workflow execute command. This replaces the previous peak workflows trigger <workflow_id> command.
Commands for listing executions and resources have been updated as follows:
- To list executions, use peak workflows list-executions <workflow_id> instead of peak workflows executions <workflow_id>.
- To list resources, use peak tenants list-instance-options --entity-type workflow instead of peak workflows resources <workflow_id>.

Changes in Workflow Specs and Deployments

Workflow specs and deployments are now managed under Press Blocks.

Workflow specs are now Block specs. More information can be found here.
- archieve and unarchive functionality for specs can now be achieved through update metadata command of the block spec through which status and other metadata of the spec can be updated.
- peak workflows specs releases is now peak blocks specs list-releases. More information can be found here.
- peak workflows specs create is now peak blocks specs create. More information can be found here.
- Previously, we used peak workflows update for updating the spec metadata and creating the new spec release. But now, we can update the metadata using update-metadata command for block spec. To create a new release, we can use spec create-release command for block spec.
Workflow deployments are now Block deployments. More information can be found here.

Please note that the listing of deployment revisions is currently not available. However, support for it will be added soon.

Changes in Apps

We now don’t need to pass artifact or src_directory, while creating an app spec. App specs can now be created by using existing block specs.
We can now update featured state of the spec by using spec update-metadata command. This can be used in place of peak apps specs featured command.
Previously, we used peak apps specs update for updating the spec metadata and creating the new spec release. But now, we can update the metadata using spec update-metadata command. To create a new release, we can use spec create-release command.
peak apps specs releases is now peak apps specs list-releases. More information can be found here.