CI Stage Settings
This topic provides settings and permissions for a CI Stage.
In this topic:
- Stage Name
- Clone Codebase
- Configure Codebase
- Repository URL
- Stage Details
- See Also
Role(s) required for CRUD in Pipeline stage: Project Admin, Project Member.
The unique name for this stage.
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.
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.
The full URL for the codebase.
The name of the stage and the Clone Codebase option.
You can edit the stage name.
See Tags Reference.
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,
If you enter
/vol, the workspace will be
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.
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.
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.
The Kubernetes namespace in the target cluster to use.
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.
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.