Harness Git Experience overview
Harness Git Experience lets you store configurations for your resources like pipelines, input sets in Git. You can choose Git as the source of truth and use your Git credentials to access and modify…
Harness Git Experience allows you to store your resource configurations, such as pipelines and input sets, in Git. You can use Git as the single source of truth and modify your configurations using your Git credentials.
With Harness Git Experience, you can easily select the repository and branch from which to execute your pipelines. This provides seamless access to your Harness resources and their configurations stored in Git, simplifying your pipeline execution.
Before you begin
Make sure you have a Git repo with at least one branch.
Make sure you have a Harness Git connector with a Personal Access Token (PAT) for your Git account.
Supported Git providers
The following Git providers are supported for Harness Git Sync:
GitHub
Bitbucket Cloud
Bitbucket Server
Azure Repos
GitLab
Make sure feature.file.editor is not set to false in the bitbucket.properties file if you are using Bitbucket on-prem.
Supported Harness entities
You can save the following Harness resources in Git using Harness Git Experience:
Pipelines
Input sets
Templates
Services
Environment
Infrastructure Definitions
Overrides
OPA Policies
What is Harness Git Experience?
Harness Git Experience lets you choose a Git-First approach for managing Harness configurations as code, using Git as the source of truth.
You can do this by creating a resource with the Remote option and specifying the Git repo and branch where you want to save your configurations.
For example, you can create a pipeline by choosing the Remote option and save it in Git by providing the repo name and branch name along with the file path.
Harness Git Experience lets you modify the configurations stored in Git through the Harness UI and save it back to Git.
You can save the modifications in the existing branch or a new branch through a PR.
Harness Git Experience workflow
When you create a Remote resource in Harness, the configurations are stored in Git.
You can select the branch from which you want to run the pipeline.
You can also select the branch in the Run Pipeline settings.
Click to view full size image During pipeline execution, the configurations of the required resources and any referenced entities like input sets, are fetched from Git.
If the referenced entities exist in the same repo, they are fetched from the same branch that you have selected for pipeline execution.
If the referenced entities exist in a different repo, they are fetched from the default branch of the repo where the entities are stored.
Harness resolves all the dependencies and then proceeds with the pipeline execution.
Key features
Here are the key features of Harness Git Experience:
Multiple repo support
Your Harness resources and their configurations can exist in multiple repos. You can choose the repository where you wish to make the modifications before pushing each configuration. At pipeline execution, Harness pulls them all together to execute your pipeline as you designed it. This gives you the flexibility to manage your Git repositories in the way you want.
You can store your configurations in the following ways:
Store configuration files along with the code repository.
Store configuration files in a repository separate from the code.
Store the prod configurations in one repo, and the non-prod ones in another repo, so that only the selected developers can access prod configs.
Store the configuration files of different environments in different branches.
Store the pipelines in one repository, and other configuration files in another.
Repository listing
For a certain connector, you can now search for repositories with support for infinite scroll. Simply enter any keyword to see related repositories listed. If you can't find the repository you're looking for, you can also add it manually.
If the repository actually exists it will fetch the branch name, if not it will throw an error.
Repository listing limits
Repository listing returns one page of repositories per API call rather than the full list. As a result, a repository that falls outside the current page does not appear in the repository dropdown, even though the repository exists.
An account can contain thousands of repositories, and fetching every repository on each dropdown interaction adds latency and increases the load on your Git provider rate limits.
Repository search narrows that list, but search runs only on the V2 repository listing flow. If the repository dropdown does not filter as you enter text, one of the following applies:
The
CDS_LIST_REPO_V2feature flag is not enabled. Without the V2 flow, the dropdown does not filter as you enter text, so you scroll the paginated list instead. Contact Harness Support to enable the flag.The connector is a root GitHub connector. V2 repository listing does not support root GitHub connectors that use the
github.comURL without any account or org name. Harness falls back to the V1 flow, which lists repositories without the V2 search and infinite scroll enhancements. Create the connector at the organization level instead.The connector is an Azure Repos connector. Search in repository listing is not supported for Azure Repos.
The connector is a GitLab connector and you entered a path. Search matches the repository name only, so a value such as
subgroup/projectreturns no matches. Enter the repository name by itself.
To select a repository that the dropdown does not list, enter the full repository name manually. Harness resolves the repository directly, so the entity saves successfully once you provide the exact name.
Branch Listing
You can now search for branches in a given repository with support for infinite scroll while creating remote entities. Simply enter any keyword to see related branches listed. If you can't find the branch you're looking for, you can also add it manually.
Branch listing limits
Harness returns a maximum of 100 branches per branch listing API call. A repository can contain thousands of branches, and fetching the full list on every dropdown interaction adds latency and increases the load on your Git provider rate limits. This limit is added to reduce the latency and load on your Git provider.
As a result, a branch that falls outside the returned set does not appear in the branch dropdown, even though the branch exists in the repository. This is most visible with newly created branches in repositories that have a large number of branches.
To select a branch that the dropdown does not list, enter the full branch name manually. Pipeline execution uses the branch name directly and does not depend on the branch listing API, so the pipeline runs successfully once you provide the exact name.
For GitHub App connectors, typing in the branch dropdown does not refresh the list, because the GitHub branch listing API accepts no search term. Enter the full branch name manually instead.
For GitHub connectors, branch search and pagination are supported through the V2 branch listing API, which requires Harness UI version 1.145.x or later, ng-manager 1.157.x or later, scm-service 1.55.x or later, and Harness Delegate version 26.06.8950 or later. Go to Delegate upgrades and expiration to upgrade your delegate.
Supported Git Providers for Repository and Branch Listing
Github
Yes
Yes
Bitbucket SAAS
Yes
Yes
Bitbucket Server
Yes
Yes
Azure
No
Yes
Gitlab
Yes
Yes
Github App
Yes
No
Harness Code
Yes
Yes
Repository listing is not supported in Azure Repo, but users can manually type in the desired repository name and add it.
Branch Listing is not supported in Github Apps, but users can manually type in the desired branch name and add it.
Repository listing returns one page of repositories per API call, and repository search requires the V2 repository listing flow. Go to Repository listing limits to understand the impact.
Branch search for GitHub requires the minimum UI, ng-manager, scm-service, and delegate versions listed under Branch listing limits.
Every provider returns a maximum of 100 branches per call. Go to Branch listing limits to understand the impact.
Multiple branch support
Multiple users can make commits to multiple branches for the resources that are synced with the Git Provider. This provides the flexibility for various branching workflows.
Bi-Directional sync
By default, Harness Git Experience syncs unidirectionally, from Harness to your Git repos. Enable this setting to have Git Experience sync two-way (bidirectionally) between Harness and your Git repo.
Changes made on either the Git repo or Harness are synched automatically.
For more information, go to Set up bidirectional sync for Git Experience.
Improved Git Synchronization for Pipeline Execution
Harness has improved Git synchronization behavior to ensure that pipeline executions always use the latest YAML configurations.
Previously, a pipeline trigger could run before the latest Git update was processed, leading to inconsistent executions. Now, with sequential processing, Harness completes the Git update first and then runs the pipeline. This guarantees that the latest YAML configuration is always used.
Note that for large Git payloads, this may introduce a small delay in trigger execution.
For more information on triggers, go to Set up Git triggers with Git Experience.
OPA policy enforcement for Git-backed entities
Harness evaluates onSave Open Policy Agent (OPA) policies when you commit a change directly to a Git-backed entity, not just when you save it in Harness. If the latest commit fails policy evaluation, Harness blocks pipeline execution until you commit a change that passes. This keeps entities changed directly in Git governed the same way as entities saved in Harness.
Go to Enforce onSave policies on Git entities to understand how this enforcement works.
What can I do with Harness Git Experience?
Harness Git Experience helps you do the following:
Store and retrieve your Harness configurations to/from Git.
Change the Harness configuration just by changing the YAML files in Git.
Add a remote pipeline in Harness, and it gets added to your specified Git repo and branch.
Maintain your key Harness resources like pipelines, Input sets like you maintain code.
Submit config changes using the Harness pipeline Studio (GUI and/or YAML) or entirely in Git.
Make Harness pipeline or resource config changes in a branch, test it in isolation (sandbox), and submit changes to master using Harness Manager or your Git platform.
What do I need to enable Harness Git Experience?
Git connector
A Harness Git Connector is used to sync your Harness Project with your Git repo. You can set up a Git Connector first and simply select it when setting up Git Experience, or you can create a Git Connector as part of the Git Experience setup.
You will need a Harness Git Connector to connect with the Git provider and perform operations like generating a webhook. Your Git Connector credentials are used to commit to Git when operations are performed using API.
Repository
Harness configurations are stored in repositories. These configuration files can be kept in the same repository as the code, or they can be kept separate. You can map your resources and configurations to multiple repositories.
Next steps
Last updated
Was this helpful?