Why not learn about webhooks as well?

Hi all! Hope everyone is having a good day. I guess everyone read the previous blog about git hooks. This is a more explained version of the previous post.

I mentioned that there are two kinds of git hooks. One is client side and the other one is server side git hooks. I explained some about the client side hooks so, today we’ll focus on the server side hooks. Client-side hooks are available inside your .git repository. You can edit them as you wish, remove the .sample extension, make the script executable and use it as you like.

Server-side hooks aka Webhooks are much different. You have to implement them on the server side. I’m specifically concerning about the Git webhooks because I’m currently working on a project with it.

Webhooks allow you to build or set up GitHub Apps which subscribe to certain events on GitHub.com. When one of those events is triggered, we’ll send a HTTP POST payload to the webhook’s configured URL. Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server. You’re only limited by your imagination.

EVENTS

When creating webhooks, you can choose what are the events that you want to recieve payloads for. Rather than recieving a whole bunch of payloads, you can subscribe into specific events, which will limit the number of HTTP requests to your server. By default webhooks are only subscribed to the push event [1].

Each event is correlated with with a certian set of actions that can happen to your repository. There are 38 events available at the moment including the wildcard event. The wildcard event (*) will match all the corresponding events.

Name	Description
`*`	Any time any event is triggered (Wildcard Event).
`check_run`	Any time a check run is created, requested, or rerequested.
`check_suite`	Any time a check suite is completed, requested, or rerequested.
`commit_comment`	Any time a Commit is commented on.
`create`	Any time a Branch or Tag is created.
`delete`	Any time a Branch or Tag is deleted.
`deployment`	Any time a Repository has a new deployment created from the API.
`deployment_status`	Any time a deployment for a Repository has a status update from the API.
`fork`	Any time a Repository is forked.
`github_app_authorization`	Any time someone revokes their authorization of a GitHub App. GitHub Apps receive this webhook by default and cannot unsubscribe from this event.
`gollum`	Any time a Wiki page is updated.
`installation`	Any time a GitHub App is installed or uninstalled.
`installation_repositories`	Any time a repository is added or removed from an installation.
`issue_comment`	Any time a comment on an issue is created, edited, or deleted.
`issues`	Any time an Issue is assigned, unassigned, labeled, unlabeled, opened, edited, milestoned, demilestoned, closed, or reopened.
`label`	Any time a Label is created, edited, or deleted.
`marketplace_purchase`	Any time a user purchases, cancels, or changes their GitHub Marketplace plan.
`member`	Any time a User is added or removed as a collaborator to a Repository, or has their permissions modified.
`membership`	Any time a User is added or removed from a team. Organization hooks only.
`milestone`	Any time a Milestone is created, closed, opened, edited, or deleted.
`organization`	Any time a user is added, removed, or invited to an Organization. Organization hooks only.
`org_block`	Any time an organization blocks or unblocks a user. Organization hooks only.
`page_build`	Any time a Pages site is built or results in a failed build.
`project_card`	Any time a Project Card is created, edited, moved, converted to an issue, or deleted.
`project_column`	Any time a Project Column is created, edited, moved, or deleted.
`project`	Any time a Project is created, edited, closed, reopened, or deleted.
`public`	Any time a Repository changes from private to public.
`pull_request_review_comment`	Any time a comment on a pull request’s unified diff is created, edited, or deleted (in the Files Changed tab).
`pull_request_review`	Any time a pull request review is submitted, edited, or dismissed.
`pull_request`	Any time a pull request is assigned, unassigned, labeled, unlabeled, opened, edited, closed, reopened, or synchronized (updated due to a new push in the branch that the pull request is tracking). Also any time a pull request review is requested, or a review request is removed.
`push`	Any Git push to a Repository, including editing tags or branches. Commits via API actions that update references are also counted. This is the default event.
`repository`	Any time a Repository is created, deleted (organization hooks only), archived, unarchived, made public, or made private.
`repository_vulnerability_alert`	Any time a security alert is created, dismissed, or resolved.
`release`	Any time a Release is published in a Repository.
`status`	Any time a Repository has a status update from the API.
`team`	Any time a team is created, deleted, modified, or added to or removed from a repository. Organization hooks only
`team_add`	Any time a team is added or modified on a Repository.
`watch`	Any time a User stars a Repository.

(If you click on any event, it’ll redirect you to a much more detailed documentation available at developer.github.com).

PAYLOADS

Each event type has a specific payload format with the relevant event information. In addition to the subscribed event, the payload will carry inforamation about the user who performed the event (sender) and the repository in which the event was triggered (repository).

I will demonstrate how I created a webhook to the project that I’m working on.

You can install webhooks on a specific repository. To do that, first go to the Settings page in your repository and click Webhooks and then Add webhook.

In there, you will be able to see some configurations that you have to fill before making use of the webhook.

Payload URL – This is the URL of the server endpoint that will recieve the webhook POST requests.
Content type – Webhooks can be delivered using two content types.
- application/json – This type will deliver the JSON payload directly as the body of the POST.
- application/x-www-form-urlencoded – This type will send the JSON payload as a form parameter called “payload”
Secret – By setting up a secret, it allows you to make certain that POST requests sent to the server is actually coming from Github.
Events – By selecting any of the event that were mentioned earlier, will trigger the webhook instantly whwever that action is taken on the repository. I ticked the ‘Let me select individual events’ as I want only a specific set of events to be triggered [2].