Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Continuous Delivery

Use the Harness CLI to manage the Continuous Delivery module, including pipelines, executions, triggers, input sets, templates, freeze windows, services, environments, infrastructure definitions, and

Continuous Delivery in Harness orchestrates how your software moves from source code to production. The CLI gives you full access to the deployment lifecycle: define pipelines as YAML, trigger executions, stream logs, and configure the services, environments, and infrastructure that make up your delivery targets.

This page covers every Continuous Delivery resource available in the CLI, from pipeline management and execution tracking to environment configuration and service overrides.

What you will learn in this topic

By the end of this page, you will know how to:

  • List, create, update, and delete pipeline definitions as YAML.

  • Execute a pipeline with runtime inputs, input sets, or YAML files.

  • Abort and retry executions, and review retry history.

  • Track execution status and retrieve step-level logs.

  • Create, update, and delete triggers, input sets, templates, and template versions.

  • Approve or reject a waiting approval instance.

  • Work with freeze windows and the global freeze status.

  • Create and manage services, environments, infrastructure definitions, and service overrides.

Before you begin

  • Harness CLI installed and authenticated: For setup steps, see Install and upgrade and Authenticate.

  • Project scope configured: Pipelines and Continuous Delivery resources require --org and --project. Set them in your profile with harness auth setscope or pass them on each command.

Pipelines

A pipeline is a YAML-defined sequence of stages and steps that orchestrates your CI/CD workflow. The CLI manages pipelines as YAML files, so you can round-trip definitions between the API and your local file system for version control and code review.

List pipelines

Get a pipeline

Returns the full YAML definition. Use --format json to convert the definition to JSON, and --raw to return the full API envelope.

For a lightweight overview without the full YAML body:

Create a pipeline

The CLI reads the identifier and metadata from the YAML body:

To create a Git-backed pipeline instead of an inline one, pass the Git connector, repository, and file path:

Update a pipeline

Fetch the YAML, edit locally, and push it back:

Delete a pipeline

Work with v1-schema pipelines

The pipeline_v1 noun provides read-only access to v1-schema pipelines for legacy API compatibility.

Execute a pipeline

Running a pipeline starts the defined stages, streams progress to your terminal, and exits with the pipeline's terminal status (0 for success, 1 for failure).

Run directly

Pass individual runtime values with --input key=value, which is repeatable. Add --follow to stream progress until the execution reaches a terminal status.

Run with an input set

Input sets are pre-saved collections of runtime values that let you repeat a known configuration without manual input. The pipeline:input_set variant uses the input set list endpoint, so Harness merges the input sets server-side.

Run with a YAML inputs file

For fully scripted CI runs, pass all runtime inputs in a file:

Run with dynamic validation

The pipeline:dynamic variant validates the pipeline YAML through the validators endpoint before it runs.

Check required inputs before running

Inspect the runtime input template to see every <+input> placeholder that the pipeline expects:

Abort and retry executions

Use interrupts to stop a running execution, and retry to re-run a failed one. Both accept the execution identifier on its own or as <pipeline_id>/<execution_id>.

Abort an execution

Interrupt a running execution. Use --interrupt-type to select the interrupt behavior.

Retry a failed execution

Retry a failed execution using the <pipeline_id>/<execution_id> format. Use --retry-stages to name the stages to retry, or --only-failed-stages to retry just the stages that failed.

Review retry history

Show the retry history and the stages that remain retryable for an execution.

Track executions

After starting a pipeline, use execution resources to monitor progress, inspect individual steps, and retrieve logs.

List recent executions

Filter the list by status, branch, or module. The pipeline identifier is optional and scopes the list to a single pipeline.

Get execution details

Add --no-graph to skip the stage and step graph in the response.

List steps in an execution

Each execution breaks down into individual steps with their own status and duration. The expanded list includes loop and matrix iterations.

Retrieve execution logs

List the log keys for an execution, then fetch the logs for a key. Passing an execution identifier to get execution_log returns every log stream for that execution. Use --follow to stream logs live, --ui to launch the interactive log viewer, and --save to write the log to a file.

Triggers

Triggers start pipeline executions automatically in response to events such as git pushes, cron schedules, or webhook payloads. Trigger identifiers are scoped to a pipeline, so they use the <pipeline_id>/<trigger_id> format on get, update, and delete.

List and get triggers

Create a trigger

Create a trigger from a YAML body. The file carries the full trigger definition.

Update a trigger

Delete a trigger

The CLI prompts for confirmation. Pass -y to skip the prompt in scripts.

Input sets

Input sets store pre-defined runtime values for a pipeline. They let you re-run a pipeline with a consistent set of inputs without providing them manually each time. Input set identifiers use the <pipeline_id>/<input_set_id> format on get, update, and delete.

List and get input sets

Create an input set

Create an input set from a YAML body.

Update an input set

Delete an input set

The CLI prompts for confirmation. Pass -y to skip the prompt.

Templates

Templates are reusable building blocks (stages, steps, or entire pipelines) that you reference across multiple pipeline definitions. They promote consistency and reduce duplication across your Continuous Delivery workflows.

List and get templates

A get template call returns the stable version of the template.

Create a template

Create a template from a YAML body.

Template versions

Each template carries one or more versions, and exactly one of them is marked stable. Version identifiers use the <template_id>/<version> format.

List and get versions

Update a version

Set the stable version

Mark a specific version as the stable version that get template returns and that pipelines resolve by default.

Delete a version

The CLI prompts for confirmation. Pass -y to skip the prompt.

Freeze windows

Freeze windows block pipeline executions during specified time periods, typically around production releases, holidays, or planned maintenance. They protect environments from accidental deployments during sensitive windows.

Approval instances

When a pipeline includes an approval stage, execution pauses until the approval is granted. Use the CLI to view approval instances for an execution and to record a decision without opening the Harness UI.

List and get approval instances

Pass the execution identifier as a positional argument when listing.

Approve an approval instance

Approve a waiting Harness approval instance. Use --comment to record a reason, and --approver-input key=value, which is repeatable, to supply approver inputs.

Reject an approval instance

Services

A service represents what you deploy: the artifact, the manifest, and any configuration that defines your application. Services are the "what" in a Continuous Delivery workflow and stay consistent across environments.

Create a service:

Update a service:

Delete a service:

Environments

An environment represents where you deploy: production, staging, QA, or any target that receives a service. Environments hold environment-specific configuration like variables, manifests, and overrides.

Create an environment:

The type field accepts Production or PreProduction. To create the environment from a YAML body instead, pass -f <environment_file>.yaml.

Update an environment:

Delete an environment:

Infrastructure definitions

An infrastructure definition describes the target compute where a service is deployed within an environment. It specifies the cluster, namespace, region, or other infrastructure details that Harness needs to execute the deployment.

Create an infrastructure definition:

Update an infrastructure definition:

Delete an infrastructure definition:

Service overrides

Service overrides let you customize service configuration for a specific environment. They override manifests, variables, or config files without modifying the base service definition, which keeps your service portable across all environments.

Create a service override:

The type field accepts ENV_GLOBAL_OVERRIDE or ENV_SERVICE_OVERRIDE.

Update a service override:

Delete a service override:

Related articles

PreviousPlatform
NextArtifact Registry

Last updated

Was this helpful?