Information for:

# Workflows with the pipelines client¶

After you have installed and configured the pipelines client (which is required only if you want to manage pipelines from the command prompt), complete the following steps to create an application with the command-line client:

1. Create a build definition file that describes how to build your application and add it to the root of your workspace.

2. Build your application using the start command.

Note for GitHub users

As an alternative, you can use the Cloud Platform pipelines integration in the user interface, in which case creating a pull request, pushing a tag, or pushing a branch in GitHub triggers a pipelines build.

When you run the pipelines start command in a Git repository that has an Cloud Platform repository as a remote, the start command determines the correct application ID. However, if your local Git repository has only GitHub as a remote, the start command cannot determine the correct application ID on its own. You can set the correct application ID for a specific repository using the pipelines set-application-id command.

To determine the correct application ID, run the pipelines list-applications command, and then find the application ID associated with the application that you want. Then, from the Git repository that you want to configure, run the following command:

pipelines set-application-id --application-id=[application ID]

3. Use the status command to verify if the build has completed and whether it was successful. If you use the Cloud Platform pipelines GitHub integration, you can see job completion and success information on the GitHub pull request. You still need to use the status command for information about commits that are not part of a pull request.

4. If desired, deploy your build artifact.

## The build artifact¶

After the build is complete, the build artifact, named pipelines-build-[BRANCHNAME] by default, is committed to your Cloud Platform repository in a build branch.

The output of the pipelines start command displays the path of the build branch in the repository. The build branch is then available for deployment into one of your Cloud Platform environments.

### Why is the build artifact created in the repository?¶

Storing the build artifact in your Cloud Platform repository provides the following advantages over alternatives such as creating a tarball:

• You can easily deploy the build artifact to your Cloud Platform environments, using the Cloud Platform interface or the Cloud API.
• You can easily view the build artifact using Git.
• You can more easily debug your build process, comparing the build artifact against what you may have expected, and compare build artifacts over time, using a tool like git diff.
• You can control how long your build artifacts are retained, since you control the contents of your own repository. You may, for example, have compliance requirements that mandate keeping them for a specified time, or security concerns that require you to be able to delete them promptly.
• You can easily copy a build artifact to other systems for such purposes as static code analysis or license compliance.

## Deploying the build artifact¶

After you have successfully completed a build, you can deploy the resulting build artifact in any Cloud Platform environment. You can do this by selecting the build branch for deployment, using either of the following methods:

After you set the deployed branch of an environment to a build branch, each build artifact committed to that branch is deployed immediately, without requiring any intervention. For example, if you build the master branch, and your Cloud Platform development environment is set to the pipelines-build-master branch, the build artifact is deployed immediately to that development environment when the pipeline job completes successfully.