You can also use a Git repo for your entire Harness Application, and sync it unidirectionally or bidirectionally. For more information, see Configuration as Code. There is no conflict between the Git repo used for remote Manifests files and the Git repo used for the entire Harness Application.
Step 1: Add a Source Repo Provider
To use a remote Git repo for your resource files or Helm charts, you must set up a Harness Source Repo Provider to connect to your repo. To set up the connection, see one of the following:
In Source Repository, select a SourceRepo Provider for the Git repo you added to your Harness account. For more information, see Add Source Repo Providers.
In Commit ID , select Latest from Branch or Specific Commit ID.
In Branch/Commit ID (required), enter the branch or commit ID for the remote repo.
In File/Folder path(s), enter the repo file and folder path.
If you want to use Go templating in your remote repo for your configuration files in Manifests, ensure that the values.yaml file is at the root of the folder path you select.
When the remote manifests are added, the Manifests section displays the connection details.
Option: Skip Versioning for Service
By default, Harness versions ConfigMaps and Secrets deployed into Kubernetes clusters. In some cases, you might want to skip versioning.
In some cases, such as when using public manifests or Helm charts, you cannot add the annotation. Or you might have 100 manifests and you only want to skip versioning for 50 of them. Adding the annotation to 50 manifests is time-consuming.
Instead, enable the Skip Versioning for Service option in Remote Manifests.
When you enable Skip Versioning for Service, Harness will not perform versioning of ConfigMaps and Secrets for the Service.
If you have enabled Skip Versioning for Service for a few deployments and then disable it, Harness will start versioning ConfigMaps and Secrets.
Option: Helm Command Flags
Enable this option to have Harness run Helm commands and their options when this Helm chart is deployed.
There are several Helm commands supported. Click the Command Flag Type dropdown to see the commands.
Next, in Input, add any options for the command, such as --debug.
If you use Helm commands in the Harness Service and in a Workflow deploying that Service, the Helm commands in the Harness Service override the commands in the Workflow.
At deployment runtime, the Harness Delegate pulls the remote configuration files from the repo and then uses them to create resources via the Kubernetes API. It does not matter if the Delegate runs in the same Kubernetes cluster as the deployed pods. The Kubernetes API is used by the Delegate regardless of the cluster networking topology.
When you deploy a Workflow or Pipeline that uses this Service, you can see the Delegate fetch the Manifests files from the repo in the Fetch Files section of the log Harness Deployments: