Welcome to the NZRT Wiki Podcast. Today we’re looking at GitHub Integrations Overview.

If you’ve ever wondered how GitHub connects to all the other tools in your development workflow, this episode is for you. GitHub doesn’t just sit on its own as a code repository. It’s designed to talk to a wide range of external services, and understanding how those connections work will help you make sense of how NZRT’s systems stay in sync.

Let’s start with the big picture. There are a few different ways GitHub can integrate with other tools, and each one works a little differently depending on what you need.

First up, you have webhooks. Think of a webhook as GitHub tapping another service on the shoulder the moment something happens. When a developer pushes code, opens a pull request, or publishes a release, GitHub sends a real-time notification to an external service of your choice. That could be Slack, Discord, or even a custom server you’ve built yourself. The notification arrives as an HTTP POST request, which means GitHub is essentially packaging up the event details and delivering them straight to wherever you’re listening.

Next, there are OAuth Apps. These are third-party applications that can access your GitHub data, but only after a user explicitly authorises them. You’ve probably seen this pattern before when a website asks you to sign in with GitHub and then lists what permissions it’s requesting. That’s OAuth in action.

Then you have GitHub Apps, which are a more modern and fine-grained option. Instead of acting on behalf of a user, a GitHub App operates with its own identity and can be granted very specific permissions over your repositories. This makes them more suitable for automation and backend tooling.

There’s also the GitHub Marketplace, which is an official catalogue of integrations covering things like continuous integration and deployment, security scanning, and project management. And finally, GitHub supports status checks, which let external services report back on whether a pull request is safe to merge. If your test suite fails, for example, the status check can actually block the merge until things are fixed.

Now let’s talk about what NZRT is actually using. There are six services in the current integration picture. Starting with the active ones, you have the WordPress GitHub Integration, which handles product synchronisation and deployment. Alongside that is the Dolibarr GitHub Integration, which keeps the ERP system in sync and also handles deployment. Slack is also active, receiving build notifications and alerts. And VS Code connects directly to GitHub, giving developers an IDE integration that lets them work with repositories without leaving their editor.

Two more services are planned but not yet active. Codecov will handle code coverage reporting, giving the team visibility into how much of the codebase is covered by tests. And DataDog will come in for performance monitoring once it’s set up.

Now let’s look at the types of events that GitHub sends out via webhooks, because understanding these helps you know what can trigger activity in those connected services.

There are six common event types NZRT works with. The first is a push event, which fires whenever new commits land on any branch. The second is a pull request event, and this one is quite broad. It triggers when a pull request is opened, when new commits are added to it, when it’s reopened after being closed, when it’s closed without merging, and when it’s actually merged. So there’s a lot of useful information flowing through that single event type.

The third event is a release event, which fires when a release is published. This is useful for triggering deployment pipelines or notifying the team that a new version is available. Fourth is the issues event, which covers when an issue is opened, closed, or labelled. Fifth is the issue comment event, which triggers whenever a comment is added to an issue. And sixth is the workflow run event, which fires when a GitHub Actions workflow finishes. This is particularly useful if you want to notify Slack, for example, whether your automated build passed or failed.

If you want to go deeper on any of the specific integrations mentioned today, there are related notes covering the WordPress GitHub Integration, the Dolibarr GitHub Integration, the VS Code and GitHub setup, and GitHub Actions. Each of those gives you a much more detailed look at how those individual connections are configured and maintained within the NZRT environment.

So to bring it all together, GitHub’s integration layer is what turns a code repository into a connected part of your broader development and operations ecosystem. Webhooks push events out in real time, OAuth and GitHub Apps control how external tools access your data, the Marketplace gives you off-the-shelf options, and status checks help enforce quality gates on your pull requests. NZRT is actively using several of these today and has more on the roadmap.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.