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.
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.
Add a Build stage to a pipeline
-
In Harness, edit or create a pipeline.
-
Select Add Stage, and then select Build.
-
In Stage Name, enter a name summarizing the stage's purpose.
Harness automatically assigns an Id (Entity Identifier Reference) 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 are optional.
-
Configure the default codebase settings.
-
Select Set Up Stage.
-
Select the Overview, Infrastructure, Execution, and Advanced tabs to configure the stage settings, set up the build infrastructure, and add steps to the stage.
Overview
These settings are found on the Overview tab after adding a Build stage to a pipeline.
Stage Details
You can edit the Name, Description, and Tags. You can also toggle the Clone Codebase setting for this stage.
Shared Paths
You can use Shared Paths to specify paths to folders outside the default workspace. You can use this to share data across steps or customize cache paths for Cache Intelligence.
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
. 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.
Cache Intelligence
Use these settings to enable and configure Cache Intelligence.
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 that Harness can use to store and manage your caches.
SLSA Provenance
These settings are for the Harness SCS module.
Advanced: Stage Variables
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.
Infrastructure
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.
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.
- Cloud
- Kubernetes
- Local
- VMs
Use the Cloud infrastructure option for Harness Cloud build infrastructure.
The following Platform settings are available:
- Select the Operating System: Select the relevant OS.
- Select the Architecture: Select the relevant architecture.
Use the Kubernetes infrastructure option to set up a Kubernetes cluster build infrastructure.
Kubernetes cluster build infrastructure has the following Platform settings:
- Select the Operating System: Select the relevant OS.
- Kubernetes Cluster: Select a Kubernetes cluster connector.
- 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.
For information about Advanced settings for Kubernetes cluster build infrastructure, go to Set up a Kubernetes cluster build infrastructure The following Advanced settings are available for the Kubernetes infrastructure:
Use the Local infrastructure option for a local runner build infrastructure.
The following Platform settings are available:
- Select the Operating System: Select the relevant OS.
- Select the Architecture: Select the relevant architecture.
Use the VMs infrastructure option for self-managed cloud provider VM build infrastructures.
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 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 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).
Execution
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
- Run tests
- Manage dependencies
- Share and cache CI data
- Run scripts
- Use plugins
- Security step (Harness STO)
Advanced
The Advanced tab contains settings for delegate selectors, conditional executions, looping strategies, and failure strategies.
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.
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.