CI Stage Settings

Updated 3 weeks ago by Michael Cretzman

This topic provides settings and permissions for a CI Stage.

In this topic:


Role(s) required for CRUD in Pipeline stage: Project Admin, Project Member.

Stage Name

The unique name for this stage.


See Entity Identifier Reference.


Text string.

Clone Codebase

When you select this option, Harness automatically clones your codebase repository before executing the steps of this stage.

No special configuration is required.

If you do not select the option here, you can select it in Stage Details.

Configure Codebase

These settings specify where the location of the codebase for the stage. See Edit Codebase Configuration.


A Harness Connector that connects to the repository where the codebase is located.

Repository URL

The full URL for the codebase.

Stage Details

The name of the stage and the Clone Codebase option.

Stage Name

You can edit the stage name.


Text string.


See Tags Reference.

Clone Codebase

Same as Clone Codebase above.


Harness automatically creates a temporary volume, known as your workspace. The workspace is the current working directory for each step in your Pipeline.

Enter a workspace volume, beginning with a forward slash. For example, /vol.

If you enter /vol, the workspace will be /vol/harness.

Harness clones your codebase repository to the workspace.

The workspace is ephemeral: It is created when the stage starts and is destroyed after the stage completes.

The workspace is a volume and, therefore, filesystem changes are persisted between Pipeline steps.

Individual steps can communicate and share state using the workspace filesystem.

Share Paths

By default, steps in a stage share the same workspace volume. For example, the maven m2 repo is stored in /root/.m2 by default. So, you can specify the same in shared paths/root/.m2 when using the maven install in a later stage.

You can add additional volumes in Shared Paths.


Environment variables are available to all steps in the stage.


This functionality is limited temporarily to the platforms and settings you can see. More functionality for this feature in coming soon.

Infrastructure is where the build is run. It is a build farm. For example, a Kubernetes cluster. The cluster uses a container to execute Run steps in the stage.

See Run Step Settings.

Select a Kubernetes Cluster

A Kubernetes cluster can be used as a build farm.

See Setting up a Kubernetes Cluster Build Infrastructure.


The Kubernetes namespace in the target cluster to use.


Service Account

A service account provides an identity for processes that run in a pod. Assume a CIE Stage Step wants to print all of the pods in the build farm infrastructure. When you specify a Service Account name, the pod container is granted Service Account permissions. It can use the granted permissions to call the Kubernetes API of the same cluster.

Run as User

The Run as User field specifies that all processes run with the user ID for any containers in the pod. Set the value to specify the user id for all processes in the pod. A typical example of Run as User field entry would be 1000.

Init Timeout

Timeout for the initialization phase. During this phase, Harness downloads the build step images and spins up the containers to execute the build steps.


Kubernetes Annotation to the pod YAML that will be used to create the pod in which the stage's steps will be executed. See Annotation.


Key/Value pair that will be added to the Kubernetes pod YAML, which is used to create the pod in which the stage's steps will be executed. See Labels.


The Execution section is where you add the steps that are performed in this stage.

See CI Technical Reference.

See Also

Please Provide Feedback