Scoping Delegates for Triggers with Webhook Authentication

Hello Everybody.


Triggers make our lives easier, they automate deployments using a variety of conditions, one of these conditions we will be focusing on are Git events, specifically Webhooks. These Triggers respond to the Web-hook event like code merges or artifact updates for a Harness Build and Deploy the Pipeline/Workflow.

Harness also supports Webhook Authentication when configuring a Trigger. Our Git provider includes secret tokens that enable you to validate requests. We can define this token as a Harness secret in our Webhook secret setting so that when the Git provider sends a POST request to the Harness URL in the Webhook, Harness will use the secret to validate the request.

This Feature is locked behind a Flag “GITHUB_WEBHOOK_AUTHENTICATION”. This improves the security of the triggers by ignoring the invokes from an inauthentic source. Even if someone get the access to the Webhook somehow, it will not be able to trigger the deployments.

Having said that, I have noticed some customers facing issue when setting this up and using scoping for certain delegates to handle this task type.

In this Article I will share with you how to setup a Workflow Trigger using Webhook Authentication for Git Events and dive into common issues that can arise when combining this with Delegate scoping and how we can resolve them.

Lets Get Started !



In order to test the Trigger and Webhook Authentication we would require an simple K8s Application in Harness that runs a Rolling Workflow to deploy an Nginx Image.

The Workflow would look something like this

Step-1 : Setting up the Trigger & Webhook Authentication

To execute the above Workflow on a Git Event we would need to add a Trigger to perform this action.
For the purpose of this exercise we will be using the Payload type : Github

When you set up the Webhook Secret for this Trigger in your Git provider, enter the value of the Harness secret in the Webhook secret’s settings. Do not enter the secret name.
This improves the security of the triggers by ignoring the invokes from an inauthentic source

Step-2: Scoping Delegates to the Trigger

When we require a certain Delegate to run the Triggered Workflow we can achieve this by using Scoping. In the case of this example we will add an Include Scope to the Delegate to limit it to a certain Application.


Once we push a new Artifact to Git we see it Triggers the Deployment based on the Webhook Git event.

Now that we have an understanding of how this works lets dive into the Common Issues we can come across !

Common Issues:

Error: No Delegates Found

This an interesting issue which can be caused due to the common misconception of the Task type of the Git Webhook Authentication and scoping.

Let’s consider the following use case where it is our requirement for one particular delegate to handle the task of Webhook Authentication and run the Trigger. In order to isolate and limit the Delegate to this case we supply it with 2 scopes :

Here we have scoped delegate “zee-k8s” to run only Task type Git (for the Webhook Authentication) and Application level scoping to use this delegate when a Workflow from that particular Application is executed.

Now let’s push an Artifact to our Git Repo to Trigger the Webhook and execute the Workflow.

We see on the Git end that the delivery we just pushed has run into the error :
Error: Delegates are not Available

This should not be the case as we have limited the scope on the Delegate to consider the Task Type Git. Due to the delivery not going through our Workflow is not Triggered.

Now lets look into what’s the cause of this issue.

The reason Git complains of not finding any Delegates is due to the use of the wrong Task Type in the scopes. We have used the Task type: Git when it should actually be Trigger.

The reason the Task Type should be Trigger is because at the Backed the Task Type for Webhook Authentication is not Git based.


The Task type is actually Trigger based. So let’s make the scope changes to use the following Task Type and Observe the behaviour.

Let’s now push a new Artifact to our Git Repo.

We see that now the Delegate is able to process the delivery and we no longer see the previous issue with “No Delegates Available”. If we check on the Harness UI we can now see the Workflow has been executed and the scoped delegate is the one being used.