Creating WebHooks with GIT

Similar to Azure DevOps, you can set up a WebHook in GIT to collect data when changes are made to the system. Webhooks in GIT are not global and apply to each project you configure them on.

Configuring Your Webhook

To start, you create your HTTP “listener” URL and add that to GIT.

It’s important to note, that for simplicity, it’s best to use the application/json content-type, otherwise your data will through as a typical form submission.

Similar to Azure DevOps, there is a significant amount of data you can retrieve from your Webhook, when you configure it, in this scenario, I’m focusing on Issues content.

Creating the Webhook Listener

Below is some sample code that I used with Azure Functions to create an HTTP Listener Webhook

[Function("GitWebHook")]
public async Task<HttpResponseData> RunAsync([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = "git/{Id}")] HttpRequestData req, string Id)
{
_logger.LogInformation("Receiving Message...");


System.Diagnostics.Debug.WriteLine("------------------------");
System.Diagnostics.Debug.WriteLine(req);
System.Diagnostics.Debug.WriteLine("------------------------");

_logger.LogInformation($"C# Git HTTP trigger function processed a request with data {req}.");
var response = req.CreateResponse(HttpStatusCode.OK);
return response;
}


In my case, I had another parameter called “Id” that I added into my route for the URL, but other than that, with this snippet you’ll be able to an idea of the full JSON information you can parse and handle from there.

About GIT Webhook Data

What I like about the GIT webhooks is the way pertinent information is structured and how it appears when you receive your data. Having the action outside of the main issue saves on parsing to find what is happening.

In GIT, it’s important to remember that everything is an issue (so no additional work item types like JIRA or AzureDevOps) and everything else is delineated by the labels themselves. Which can get tricky as well, because you can assign multiple labels to an issue (i.e., it can be a bug… or a task).

The one other thing that took me a bit to figure out when I was doing my testing is that the GIT Webhook generates lots of traffic since it acts on every change with no true save data. Not only this, but based on what you change, you will only get data for that event and not a list of fields with empty data.