Configuring a webhook for GitHub

 

Using Webhooks for Serverless Development, Part 2 Configuring a Webhook for GitHub

Webhooks provide an easy way for apps to be notified of events by other outstaffing services via an http endpoint. In this part of our workshop, we use GitHub’s webhook feature to update a wiki page.

Company about the topic

A fully defined webhook at GitHub that informs a wiki about changes to the repository.A fully defined webhook at GitHub that informs a wiki about changes to the repository.

(Image: Drilling / GitHub)

On GitHub, webhooks can be set up for an organization or a selected directory. The webhook is triggered whenever at least one or more of the subscribed events occur.

The event “Gollum”is interesting for our purpose. This allows the developer to create a webhook that listens, for example, to updates to his GitHub wiki regarding the creation and update of a wiki page. To do this, navigate to the “Settings” page of your repository in the GitHub portal and click on ” Webhooks“ …

Webhooks are a feature built into GitHub.Webhooks are a feature built into GitHub.

(Image: Drilling / GitHub)

… and click on the “Add webhook” button. Some settings have to be made on the corresponding page. To do this, you first have to be clear about what you mean by an event and which event types, for example, GitHub supports, because events are the linchpin of webhooks. They occur, for example, when actions are performed in the repository.

In this case, the webhook is triggered, gets the URL specified in “Payload URL”, and sends the payload and other event information to that URL. All webhook events supported by GitHub and information on when they can be executed can be found on the GitHub Webhook events and payloads page.

The configuration page for a GitHub webhook.The configuration page for a GitHub webhook.

(Image: Drilling / GitHub)

So let’s get back to the setting options on the GitHub”Add webhook”page. The terms in question are the following: The “Payload URL” is the URL of the server that receives the webhook POST requests.

Each event type has a specific payload Format. This payload contains the information about the event that triggered the Webhook. We determined the URL of our http trigger for the Azure function in part 1 of our workshop. It looks something like this:

https://devinsiderfa.azurewebsites.net/api/httpTrigger1?code=pRdaxdg7T4UK2KMa87rq9aytXK6/e0X9eE94EyLXMdSFNTkXWR23Gg==

We want to inform our external Azure function about changes on the wiki page.We want to inform our external Azure function about changes on the wiki page.

(Image: Drilling / GitHub)

“Content type “means that webhooks are transmitted on the basis of two different content types: With the content type” application/json”, the JSON payload is transmitted directly as the text of the POST request. With the content type “application / x-www-form-urlencoded”, the JSON payload is transmitted as a form parameter with the name “Payload”.

The fully configured webhook on GitHub.The fully configured webhook on GitHub.

(Image: Drilling / GitHub)

At ” Which events would you like to trigger this webhook?”then we select the option” Let me select individual events.”and check “Wiki” there to listen to updates in the wiki of our repository. This is exactly the Gollum event mentioned above. Then we click on “Add webhook”. The result should look something like the one shown in the preceding figure.

Webhook test

A first test of our webhook.A first test of our webhook.

(Image: Drilling / GitHub)

To test our webhook, we click the “Wiki” tab in the GitHub portal for our repository, select the page we created before and click “Edit”. There we enter e.g. “Webhook Test”.

The request-playload of our webhook.The request-playload of our webhook.

(Image: Drilling / GitHub)

Then we navigate to “settings / Webhooks”, where we find a corresponding Push-entry. There we click on ” Edit “and then navigate to the section”Recent Deliveries”. Here you can see only an ID of the form “a18aa670-49c7-11eb-836f-4c9fe122677e”. But if you click on the three points on the right, we also see “Header ” and” Payload ” in the “Request” tab ….

The Response Body of the response to the Webhook.The Response Body of the response to the Webhook.

(Image: Drilling / GitHub)

… as well as “Header” and “Body” in the “Response” tab, each with the successful http status code 200. In addition, we can also take the detailed information from the payload that our wiki page has been edited. The payload consists of the sections “pages”, “repository”, and “station”.

Conclusion

In this part of the workshop, we saw how we can listen to Gollum events in our GitHub repository, specifically changes to the wiki page, by setting up a suitable webhook on GitHub. In part 1, we also showed how a serverless Azure function can be triggered by an external http trigger.

In the third part, we will take a closer look at the payload from the “Gollum” event and then adjust our Azure function so that it analyzes the payload from the Webhook event in our sense and responds appropriately to it.

(ID:47109095)

Ready to see us in action:

More To Explore

IWanta.tech
Logo
Enable registration in settings - general
Have any project in mind?

Contact us:

small_c_popup.png