Clone repository

Overview of the Clone repository job step, which clones the repository during Job execution.

From the job step settings (Figure 1), you can customize information about the job step, including:

• A custom step name can be defined; otherwise, the default step name will be used
• Select one of the Repositories that will be cloned during execution of the Job. Repository value can be set to None. If a repository is chosen, additional cloning options will become available.
  Note: Please note that a problem may occur with long paths, when trying to clone a repository on Windows machine. If that happens consult Git clone troubleshooting guide page for more information.

  

• You can define the branch that will be cloned during Execution of the Job. Pro tip: The branch can be a Job parameter. An example is available here.
• Clone options for additional clone repository configuration:
  1. You can define the depth you wish to use for cloning (i.e. Depth limits the size of cloning to last n commits).
  2. You can define the maximum number of retries for the git clone or pull action in the event that the action fails.
  3. You can define destination where the repository should be cloned as a relative directory path within the Agent's working directory. If left blank, the repository will be cloned within the Agent's working directory
  4. When the repository is first cloned for any Agent, Officer keeps a copy of the repository in cache. When a new Job is started, it will Pull the repository from cache whenever possible instead of cloning the repository from the beginning. If Clear cache field is marked, all the repository data will be deleted before this job step, forcing the entire repository to be cloned.
     Note: Using the Clear cache field may lead to execution performance degradation.
  5. The sparse checkout option allows you to work with a specific subset of files or directories within a large Git repository. This approach helps reduce disk usage and speeds up operations by eliminating the need to check out the entire repository. It is particularly useful when working with monorepos. For more information about the sparse checkout option, refer to the Git documentation. When performing a sparse checkout, sparse paths should be defined to indicate which directories need to be checked out, rather than checking out the whole repository, as shown in the figure below.

     

     Note: Please be aware that Git sparse was first introduced in version 2.25.0. If your installed Git is older, you will need to update it in order to use this feature. Using the sparse option on TestHub with an older Git version will result in an error during the cloning of the repository.
• Every step has Advanced options through which steps can be managed. When execution of the step fails, execution of the job continues. If option Abort job on step fail is marked, Job execution will stop once this step fails and further steps will not be executed. When it comes to skip condition, it allows skipping the current step if the condition is met.