Currently, the Git Clone step in Deploy stages is behind the feature flag
CDS_CONTAINER_STEP_GROUP. Contact Harness Support to enable the feature.
Add a Git Clone step to clone a repository into the CD stage's workspace.
By cloning the repository, you gain access to the necessary code, scripts, or configurations, enabling you to perform various actions and ensure a reliable and controlled deployment.
Example uses cases for cloning a repository in a CD stage
- Accessing deployment scripts or configuration files:
- Cloning a repository allows you to access deployment scripts, configuration files, or other resources needed for the deployment process. By cloning the repository, you can ensure that the latest versions of these files are used in the deployment, providing consistency and avoiding potential issues caused by outdated or mismatched files.
- Retrieving application or infrastructure definitions:
- In cases where the CD process involves deploying an application or provisioning infrastructure, cloning the repository enables you to retrieve the application's source code or the infrastructure-as-code (IaC) definitions. By having the codebase or infrastructure definitions locally, you can perform necessary tasks such as building the application image or running tests.
- Branch or commit specific deployments:
- Cloning the repository allows for branch or commit-specific deployments. For instance, you might have a CD pipeline that triggers deployments based on specific branches, such as staging or release branches. By cloning the repository, you can isolate the relevant code for the specific branch or commit and perform targeted deployments.
- Performing custom build or pre-deployment actions:
- Cloning a repository provides the opportunity to perform custom build or pre-deployment actions. These actions might involve running additional tests, compiling assets, generating documentation, or preparing the application or infrastructure for deployment. By cloning the repository, you have full control over the deployment process and can add any necessary steps before deploying.
- Verifying deployment artifacts:
- Cloning the repository allows you to verify the integrity and consistency of the deployment artifacts. By comparing the cloned repository with the expected state or predefined configurations, you can ensure that the correct files and versions are being deployed, reducing the risk of deploying incorrect or unauthorized code or configurations.
Add the Git Clone step
The Git Clone step uses a containerized step group. For more information, go to Containerize step groups.
- Harness Manager
- In your Harness Deploy stage, in Execution, select Add Step.
- Select Git Clone.
- Configure the steps using the settings described below.
Select a connector for the source control provider hosting the code repository that you want the step to clone.
The following topics provide more information about creating code repo connectors:
- Azure Repos: Connect to Azure Repos
- Bitbucket: Bitbucket connector settings reference
- GitHub: GitHub connector settings reference
- GitLab: GitLab Connector Settings reference
- Other Git providers:
If the connector's URL Type is Repository, then Repository Name is automatically populated based on the repository defined in the connector's configuration.
If the connector's URL Type is Account, then you must specify the name of the code repository that you want to clone into the stage workspace.
Build Type, Branch Name, and Tag Name
For Build Type, select Git Branch if you want the step to clone code from a specific branch within the repository, or select Git Tag if you want the step to clone code from a specific commit tag. Based on your selection, specify a Branch Name or Tag Name.
You can use fixed values, runtime input, or variable expressions for the branch and tag names. For example, you can enter
<+input> for the branch or tag name to supply a branch or tag name at runtime.
An optional target path in the stage workspace where you want to clone the repo.
The number of commits to fetch when the step clones the repo.
The default depth is
0, which fetches all commits from the relevant branch.
For more information, go to the git clone documentation.
If True, which is the default value, the pipeline verifies your Git SSL certificates. The stage fails if the certificate check fails. Set this to False only if you have a known issue with the certificate and you are willing to run your stages anyway.
Set Container Resources
Maximum resource limits for containers that clone the codebase at runtime. For more information, go to Resource units in Kubernetes.
In Advanced, you can use the following options: