> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/ci-stage-settings.md).

# CI Build stage settings

This topic describes CI Build stage settings. For more information about configuring stages in CI pipelines, go to [CI pipeline creation overview](/continuous-integration/use-harness-ci/use-harness-ci/prep-ci-pipeline-components.md).

To create, edit, and delete stages in CI pipelines, you need either Project Admin or Project Member permissions. For more information, go to the [Permission Reference](/harness-ai/use-harness-platform/platform-access-control/permissions-reference.md).

### Add a Build stage to a pipeline <a href="#add-a-build-stage-to-a-pipeline" id="add-a-build-stage-to-a-pipeline"></a>

1. In Harness, edit or [create a pipeline](/continuous-integration/use-harness-ci/use-harness-ci/prep-ci-pipeline-components.md).
2. Select **Add Stage**, and then select **Build**.
3. In **Stage Name**, enter a name summarizing the stage's purpose.

   Harness automatically assigns an **Id** ([Entity Identifier Reference](/harness-ai/use-harness-platform/references/entity-identifier-reference.md)) based on the **Name**. You can change the **Id** when you first add the stage. After you add the stage, it the **Id** can't be changed.

   The description and [tags](/continuous-integration/new-to-harness-ci/overview.md#create-tags-for-pipelines) are optional.
4. Configure the [default codebase settings](/continuous-integration/use-harness-ci/use-harness-ci/codebase-configuration/create-and-configure-a-codebase.md).
5. Select **Set Up Stage**.
6. Select the [Overview](#overview), [Infrastructure](#infrastructure), [Execution](#execution), and [Advanced](#advanced) tabs to configure the stage settings, [set up the build infrastructure](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure.md), and add steps to the stage.

### Overview <a href="#overview" id="overview"></a>

These settings are found on the **Overview** tab after adding a Build stage to a pipeline.

#### Stage Details <a href="#stage-details" id="stage-details"></a>

You can edit the [Name](#stage-name), [Description](#description), and [Tags](#tags). You can also toggle the [Clone Codebase](#clone-codebase) setting for this stage.

#### Shared Paths <a href="#shared-paths" id="shared-paths"></a>

You can use **Shared Paths** to specify paths to folders outside the default workspace. You can use this to [share data across steps](/continuous-integration/use-harness-ci/use-harness-ci/caching-ci-data/share-ci-data-across-steps-and-stages.md) or customize cache paths for [Cache Intelligence](/continuous-integration/use-harness-ci/use-harness-ci/caching-ci-data/cache-intelligence.md).

When a pipeline runs, it creates a temporary volume for each stage called a *workspace*. During initialization, the stage clones your codebase to the root of the workspace. Then, the steps in the stage run inside the root. The workspace is the current working directory for each step in the stage. The workspace persists for the lifetime of the stage and enables steps in that stage to communicate and share state information. The default shared working directory for a stage is `/harness` (on macOS build infrastructure, it is `/tmp/harness`). The workspace is destroyed when the stage ends.

Individual steps can communicate and share state using the workspace filesystem. The workspace is a volume, so filesystem changes persist throughout the stage lifetime. If you need to share additional volumes, you can add **Shared Paths**. Path declarations must begin with a forward slash, such as `/vol`.

For example, the maven `m2` repo is stored in `/root/.m2` by default. If your Build stage uses Maven, you can specify `/root/.m2` as a **Shared Path** so that all steps in that stage can access that directory.

If you need to shared data across stages, use [caching](/continuous-integration/use-harness-ci/use-harness-ci/caching-ci-data/share-ci-data-across-steps-and-stages.md#share-data-across-stages).

#### Cache Intelligence <a href="#cache-intelligence" id="cache-intelligence"></a>

Use these settings to [enable and configure Cache Intelligence](/continuous-integration/use-harness-ci/use-harness-ci/caching-ci-data/cache-intelligence.md).

For fully supported build tools with dependencies stored in the default location for the tool used, you only need to select **Enable Cache Intelligence**.

For other build tools or non-default cache locations, you must provide custom cache **Paths** in addition to enabling Cache Intelligence. Depending on the cache location, you might also need to specify these paths in **Shared Paths**.

Optionally, you can specify a custom cache **Key**

If you are using self-managed build infrastructure (any build infrastructure other than Harness CI Cloud), you must also [define S3-compatible object storage](/harness-ai/use-harness-platform/settings/default-settings.md#continuous-integration) that Harness can use to store and manage your caches.

#### SLSA Provenance <a href="#slsa-provenance" id="slsa-provenance"></a>

These settings are for the [Harness SCS module](https://app.gitbook.com/s/SN2B2M5cFWy0hhD0xTuE/README).

#### Advanced: Stage Variables <a href="#advanced-stage-variables" id="advanced-stage-variables"></a>

[Stage variables](/harness-ai/use-harness-platform/pipelines/add-a-stage.md#stage-variables) are available to all steps in the stage. There are many uses for these variables. For example, stage variables are inherently available to steps as environment variables.

**Stage Timeout**

By default Harness applies a timeout (of 1 hour) on CI stages to ensure pipelines don't run indefinitely. Users can increase stage timeout to a maximum of 24 hours.

{% hint style="info" %}
On self-managed build infrastructure, when the CI\_ENABLE\_LONG\_TIMEOUTS feature flag is enabled, the maximum timeout can now be set to 35 days. This is especially useful for long running jobs like ML training or large test suites.
{% endhint %}

### Infrastructure <a href="#infrastructure" id="infrastructure"></a>

These settings are found on the **Infrastructure** tab after adding a stage to a pipeline.

Infrastructure is where the build runs the steps in this stage. It is a build farm, such as a Kubernetes cluster. Infrastructure settings vary by [build infrastructure type](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/which-build-infrastructure-is-right-for-me.md).

The first stage requires you to configure a build infrastructure. In stages after the first, you can either **Propagate from an existing stage** or **Use a New Infrastructure**.

{% tabs %}
{% tab title="Cloud" %}
Use the **Cloud** infrastructure option for [Harness Cloud build infrastructure](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/use-harness-cloud-build-infrastructure.md).

The following **Platform** settings are available:

* **Select the Operating System:** Select the relevant OS.
* **Select the Architecture:** Select the relevant architecture.
  {% endtab %}

{% tab title="Kubernetes" %}
Use the **Kubernetes** infrastructure option to [set up a Kubernetes cluster build infrastructure](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/k8s-build-infrastructure/set-up-a-kubernetes-cluster-build-infrastructure.md).

Kubernetes cluster build infrastructure has the following **Platform** settings:

* **Select the Operating System:** Select the relevant OS.
* **Kubernetes Cluster:** Select a [Kubernetes cluster connector](/harness-ai/use-harness-platform/connectors/cloud-providers/add-a-kubernetes-cluster-connector.md).
* **Namespace:** Enter the Kubernetes namespace to use in the target cluster. You can also use a Runtime Input (`<+input>`) or expression for the namespace. For more information, go to [Runtime Inputs](/harness-ai/use-harness-platform/variables-and-expressions/runtime-inputs.md).

For information about **Advanced** settings for Kubernetes cluster build infrastructure, go to [Set up a Kubernetes cluster build infrastructure](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/k8s-build-infrastructure/set-up-a-kubernetes-cluster-build-infrastructure.md) The following **Advanced** settings are available for the **Kubernetes** infrastructure:
{% endtab %}

{% tab title="Local" %}
Use the **Local** infrastructure option for a [local runner build infrastructure](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/define-a-docker-build-infrastructure.md).

The following **Platform** settings are available:

* **Select the Operating System:** Select the relevant OS.
* **Select the Architecture:** Select the relevant architecture.
  {% endtab %}

{% tab title="VMs" %}
Use the **VMs** infrastructure option for [self-managed cloud provider VM build infrastructures](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/vm-build-infrastructure.md).

The following **Platform** settings are available:

* **Select the Operating System:** Select the build infrastructure OS.
* **Pool Name:** Enter the pool name as specified in the `pool.yml` setup file in your build infrastructure.
* **Override Image Connector:** By default, [Harness pulls certain images from public Docker Hub repos](/continuous-integration/use-harness-ci/use-harness-ci/set-up-build-infrastructure/harness-ci.md) that are needed to run a build. You can override this by using a [Docker connector that downloads the images from the Harness Container Image Registry](/harness-ai/use-harness-platform/connectors/artifact-repositories/connect-to-harness-container-image-registry-using-docker-connector.md) instead. This option is useful when your default Delegate cannot access the public registry (for example, due to security policies in your organization or if your infrastructure is running in a private cloud).
  {% endtab %}
  {% endtabs %}

### Execution <a href="#execution" id="execution"></a>

The **Execution** tab is where you add steps to the stage. For details about different step types, go to:

* [Build and push images or upload and download artifacts](/continuous-integration/use-harness-ci/use-harness-ci/build-and-upload-artifacts.md)
* [Run tests](/continuous-integration/use-harness-ci/use-harness-ci/run-tests.md)
* [Manage dependencies](/continuous-integration/use-harness-ci/use-harness-ci/manage-dependencies.md)
* [Share and cache CI data](/continuous-integration/use-harness-ci/use-harness-ci/caching-ci-data.md)
* [Run scripts](/continuous-integration/use-harness-ci/use-harness-ci/run-step-settings.md)
* [Use plugins](/continuous-integration/use-harness-ci/use-harness-ci/use-drone-plugins.md)
* [Security step (Harness STO)](/security-testing-orchestration/use-sto/sto-scanner-configuration/security-step-settings-reference.md)

### Advanced <a href="#advanced" id="advanced"></a>

The **Advanced** tab contains settings for [delegate selectors](/harness-ai/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors.md), [conditional executions](/harness-ai/use-harness-platform/pipelines/step-skip-condition-settings.md), [looping strategies](/harness-ai/use-harness-platform/pipelines/looping-strategies/looping-strategies-matrix-repeat-and-parallelism.md), [failure strategies](/harness-ai/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps.md), and [Send status to Git](/harness-ai/use-harness-platform/triggers/triggering-pipelines.md#send-stage-execution-status-to-git-on-pull-requests).

{% hint style="info" %}
If you use a delegate selector with a Kubernetes cluster build infrastructure, and your delegate selector specifies a Docker delegate, your Kubernetes cluster connector must be set to [Specify Master URL and Credentials](/harness-ai/use-harness-platform/connectors/cloud-providers/ref-cloud-providers/kubernetes-cluster-connector-settings-reference.md#specify-master-url-and-credentials).

Kubernetes cluster connectors can't inherit delegate credentials (use the credentials of a specific Harness Delegate) from Docker delegates because they are not in the same environment.
{% endhint %}

{% hint style="info" %}
**SEND STATUS TO GIT**

The **Send status to Git** option lets you control how CI stages report build status to Git providers for Pull Request builds, including custom status check names and deduplication of status updates. For details, go to [Send Stage Execution Status to Git on Pull Requests](/harness-ai/use-harness-platform/triggers/triggering-pipelines.md#send-stage-execution-status-to-git-on-pull-requests).
{% endhint %}