This downloads all resources of a given app, stores them into the local workspace in order to be able to edit them. If a local resource already exists, this asks for either to overwrite or to skip.
pi get global/app/myapp/**
This command-line call downloads all resources of the app myapp and its sub-folders, and stores them into the local workspace folder properties/global/app/myapp. Note, that you have to define the property key here, not the local file path.
This downloads only the resources inside the myapp folder, but no resource from inside its sub-folders.
This command initializes a given folder as a PIPEFORCE workspace folder. It creates all necessary folder structure and configuration files in order to start development of new PIPEFORCE apps inside it. Such a workspace folder can contain one or more apps to be published to PIPEFORCE. It's also good practise to commit the whole workspace folder as single repo to GitHub (or your preferred source code management system).
This will create a file and folder structure like this:
The file config.json will contain all required settings for this workspace. Feel free adjust to your needs.
The folder properties is the default home folder for all properties which will be deployed to PIPEFORCE using the command pi publish. The structure inside this folder must correspond with the structure in the property store, you would like to deploy.
The file PIPEFORCE.code-workspace is the default workspace configuration for Visual Studio Code. Feel free to delete it in case you're using a different development environment.
This lists all available CLI options or pipeline commands.
This lists all available command-line options.
pi help command
This lists the documentation of all available pipeline commands for the currently logged-in user.
pi help command log
This explains the log pipeline command. The output could look like this:
description: "Logs the given input message without changing it. Sets the log message\
\ in the body in case body is empty. Doesn't overwrite any existing content in\
\ the body."
description: "The message to log. Can be a string or a pipe expression. If null\
\ or empty, the full pipe message will be logged."
description: "The log level. Can be one of DEBUG, TRACE, INFO, WARN, ERROR.\
\ If null or empty, INFO will be used."
This uploads your created or changed resources like pipeline or form configurations to the server.
In case a resource already exists at the server, this updates only if it has changed since last upload.
This command uploads / updates all resources inside the properties folder.
If you want to publish only a certain subset of the properties folder, you can specify the folder like this:
pi publish properties/global/app/myapp/**
This will recursively publish any resource inside this folder and its sub-folders.
In case you want to publish only the files inside this folder, but not its sub-folders and files, you can use a single asterisk instead:
pi publish properties/global/app/myapp/*
If you want to publish a single resource, define it by its filename:
pi publish properties/global/app/myapp/pipeline/hello.pi.yaml
Note, that the path argument is always relatively to your current working dir, as long as you are inside the workspace home folder $USER_HOME/pipeforce:
pi publish **
This will publish all resources inside properties/gobal/app/myapp recursively.
For security reasons (for example, to not accidentally publish a huge path structure of your file system to the server), publish is only possible in case your current working dir is inside the workspace folder.
This does a one-way-sync of files inside the local properties folder to the server. It watches a given folder, and immediately syncs changes of files inside this folder to the server.
The folder to sync must be located inside the properties folder of your workspace.
pi sync properties/global/app/myapp
This example syncs all files from the folder myapp to the server.
At the beginning of the sync, you will be asked whether you want to backup and cleanup the given folder. If you choose yes, then the content of the remote folder will be downloaded and stored in your workspace inside the backup folder, and then the remote content gets deleted. This is handy in case you want to start with a clean sync state between local and server side.
This is a one-way-sync from local to server. Changes made on the server-side will not be merged to your local sources. If you need such an approach, please refer to source managament tools like Git, for example, which have built-in merge conflict handling and concurrent editing features.
Since version v3.0.13 the CLI also contains some useful commands in order to make it easier to work with the Kubernetes backend of PIPEFORCE. These commands are intended mainly to simplify the development for backend developers and DevOps.
In order to be able to use these extended commands, kubectl must be installed and its current context must be configured in a way to successfully access to the Kubernetes cluster, the commands must be targeted to.
All commands specific to Kubernetes are prefixed with a k for example kupload.
All k-commands are executed inside the namespace of the currently active instance, selected by pi setup or pi instance.
Syncs file and folder changes (create, modify, delete) inside a local folder (recursively) with the remote folder in a container. Automatically selects the container by resolving the given service name.
pi ksync <SERVICE> <LOCAL_PATH> <REMOTE_PATH> [<CHOWN>]
pi ksync drive /Users/me/git/drive/ /var/www/html www-data:root
This example (one-way) syncs any local changes to the remote container and applies a chown with www-data:root recursively on the synced sources.
FOR WINDOWS USERS
Make sure to not use backslashes \ or drive letters like C:for example in your path. You have to rewrite a path like C:\myfolder to C/myfolder or simply /myfolder.
PIPEFORCE gives you full source code control on any of your application resources. This way you can put also the low code sources under GitOps control the same way you would do with any other source code.
The local low-code workspace is a folder on your local machine, where you can store and edit all of your low-code configuration files and scripts, and then sync them with the PIPEFORCE property store with a single call of pi publish.
You could manage all properties in the property store with the property.* commands and the CLI using pi pipeline.
This might be useful for small changes. But, if you want to develop and customize full business applications, we recommend you to use the local low-code workspace. This way you can track changes more easily and be prepared for a good change management process.
The low-code workspace will mirror the property store properties as a local hierarchy of folders and files. Any configuration and script file created locally inside this workspace, can then easily be uploaded to the property store with a single command. For example:
pi publish properties/global/app/myapp/*
This scans the folder myapp inside the workspace, and uploads only those resources which have been changed since last upload or have been created since then.
You can also use the short form of the command:
This will publish any new or changes resources inside the properties folder to the server.
Your password is never stored by the CLI for security reasons. Instead, the CLI automatically exchanges this password with an API access token and stores this access token. This token is valid for 30 days. That means: If you did not login into PIPEFORCE for longer than 30 days, you need to re-generate this access token. You can do that by simply calling pi setup later, which asks again for credentials, and then creates and stores a new access token for you if the login was successful.
Congratulations! A new property store workspace was been created for you under $USER_HOME/pipeforce
Replace $USER_HOME by the path of your user home folder, which differs depending on your current operating system.
For Windows, this is typically: C:\Users\YOUR_USERNAME
Each workspace may contain the file .pipeforce/config.json which contains all settings for your local workspace. If this file is missing, the default values will be used instead. This file will by default look like this:
propertiesHome defines the name of the folder at root of the worspace which contains all property sources which will be deployed to the PIPEFORCE backend. By default this is set to properties.
requiredVersion defines the minimum version of the PIPEFORE backend which is required in order to run the apps defined in this workspace. For example 9.0.0 or just 9. If this value is empty or null, specific version check will be done. This will be checked in case the workspace apps are installed using the command app.install or via marketplace. Default value is null.
deployWithExtension defines whether the filename extensions of the files from inside the propertiesHome folder should be kept in the property path on deployment to the property store or not. For example a file in properties/global/app/config/app.json will be deployed to a property path global/app/config/app.json if this value is set to true, or to global/app/config/app if this value is false. Default is false.
Visual Studio Code (in short: VS Code) is a free resource editor which works nicely together with the pi tool and simplifies customizing PIPEFORCE. You can also use a different editor, but we recommend you to use this one at least for the starting phase.
After you have created a resource locally, you can upload it to the property store with a simple command inside your VS Code terminal:
After the command was executed, you can see that your pipeline has been successfully created into the property store.
Anytime you change a resource in the workspace, calling pi publish afterwards, will create or update only those resources which have been changed after the last publish. This way, you can work in a very effective way.