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

If you’ve spent any time in software development, you’ve probably heard of GitHub. But let’s make sure we’re all on the same page about what it actually is and how NZRT uses it day to day.

GitHub is a cloud-based platform built on top of Git, which is a version control system. In plain terms, that means GitHub gives you a place to store your code, track every change ever made to it, and collaborate with other people without stepping on each other’s work. It also adds a layer of DevOps tooling on top, so you can automate testing, deployment, and all sorts of other workflows right from the same platform.

Now let’s walk through the key concepts you’ll encounter when working with GitHub.

First up, you have repositories. A repository is essentially a storage container for a project. It holds all the code, all the files, and the entire history of every change ever made. Repositories can be public, meaning anyone on the internet can see them, or private, meaning only people you grant access to can view them.

Next, there are forks. When you fork a repository, you create your own independent copy of it. This is really useful if you want to experiment with changes without affecting the original project, or if you’re contributing to someone else’s work and need your own space to develop.

Then you have pull requests. This is the formal process for getting your changes reviewed before they get merged into the main codebase. You make your changes on a separate branch, open a pull request, and other team members can review the code, leave comments, and approve or request changes before anything goes live.

GitHub Actions is the built-in automation engine. You can set up workflows that trigger automatically based on events, for example when someone pushes new code, opens a pull request, or on a regular schedule. This is how you handle things like running automated tests or deploying to a server without doing it manually every time.

Issues are how GitHub handles bug tracking, feature requests, and project planning. You can label issues, assign them to people, and group them into milestones to track progress toward a goal.

Releases let you package up specific versions of your software with release notes and downloadable files, so users or other systems always know exactly what version they’re working with.

GitHub Pages is a handy feature that lets you host static websites directly from a repository. It’s commonly used for documentation sites, project landing pages, or blogs.

And finally, webhooks. A webhook is a way for GitHub to send a real-time notification to another service whenever something happens in your repository. For example, you could have GitHub notify Slack every time a pull request is opened.

Now let’s talk about how NZRT specifically uses GitHub. All NZRT repositories live under the organisation at github dot com slash nzrtnetwork. The general approach is to keep documentation public so it’s accessible, while production code stays in private repositories.

For authentication, NZRT uses SSH keys alongside personal access tokens for command-line work. The preferred tool for local automation and CLI tasks is the GitHub CLI, known as gh. So if you’re scripting something GitHub-related at NZRT, that’s the channel to use.

GitHub Secrets are used to store sensitive information like API tokens and deployment credentials, keeping them out of the codebase but still available to automated workflows.

On the integration side, NZRT has connected GitHub to Slack notifications and email alerts, so the right people hear about pull request reviews and other key events without having to check GitHub manually.

One workflow worth highlighting is the Dolibarr-Custom repository, which is actively monitored by GitHub Actions. That means changes there can trigger automated processes, which is a good example of how GitHub sits at the centre of NZRT’s development pipeline rather than just being a place to store code.

So to pull it all together, GitHub at NZRT is not just a code host. It’s the central coordination point for version control, code review, automation, and integration with the wider toolset. Whether you’re pushing a small fix or managing a full deployment pipeline, GitHub is where it all comes together.

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

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

So what is GitHub Packages? Put simply, it’s a package registry built right into GitHub. Instead of relying on a completely separate service to host your libraries and containers, you can publish and install packages directly from the same platform where your code already lives. That tight integration with GitHub repositories, GitHub Actions, and GitHub authentication is what makes it particularly useful for teams already working in that ecosystem.

Let’s talk about what kinds of packages GitHub Packages actually supports, because it covers a lot of ground. If you’re working with JavaScript, you can use it as an npm registry. If you’re in the Java world, it supports Maven and Gradle. For dotnet developers, there’s NuGet. If you’re building and deploying containers, Docker images are supported. And if you’re in the Ruby ecosystem, RubyGems are covered too. So whatever stack you’re working with, there’s a good chance GitHub Packages has you covered.

Now, a few key concepts worth understanding before you dive in. First is scoping. When you publish a package, you namespace it to either your organisation or your user account. For NZRT, that means packages are published under the nzrtnetwork organisation scope. This keeps things organised and makes it clear who owns and maintains a given package.

Next is visibility. Packages can be either public or private, just like repositories. Public packages can be installed by anyone, while private packages require authentication and appropriate access.

Speaking of authentication, you’ll need a GitHub token to both publish and install packages. This ties into GitHub’s permissions model, where package access is inherited from repository access. If you have read access to a repository, you can install its packages. If you have write access, you can publish.

And then there’s CI and CD integration, which is where things get really powerful. GitHub Actions can automatically publish packages as part of your workflow, so every time you push a release, your package is built and published without any manual steps.

Let me walk you through how NZRT handles npm package publishing via GitHub Actions. The workflow step is straightforward. There’s an action step that runs npm publish, and it passes in an environment variable called NODE AUTH TOKEN, which is automatically set to the built-in GitHub token that Actions provides. You don’t need to manually create or store that token — GitHub injects it securely at runtime. That’s the publish side sorted.

On the install side, it’s just as clean. If you want to install one of NZRT’s npm packages from the command line, you run npm install followed by the package name under the nzrtnetwork scope. For example, there’s a package called wp-sync-sdk published under that scope, and installing it looks exactly like any other npm install command — the only difference is the scoped name tells npm to look at the GitHub registry rather than the default public registry.

Now let’s go through the four supported registry types NZRT is using, because it’s worth knowing what’s available. First, Docker, which is used for container images. The NZRT Docker images are hosted on the GitHub Container Registry, and there’s a WordPress base image there as an example. Second, Maven, which handles Java libraries. NZRT uses this for a Dolibarr API library under the co.nzrt group. Third, npm, which as we just covered is for JavaScript libraries. The nzrt-utils package is one example published under the nzrtnetwork scope. And fourth, NuGet, which is for dotnet packages. NZRT has a Dolibarr integration package published there.

So to bring it all together — GitHub Packages gives you a single, integrated place to host your libraries and containers, authenticate using the same tokens and permissions you already have set up in GitHub, and automate publishing through Actions. For a team like NZRT that’s already leaning heavily on the GitHub ecosystem, it removes a lot of friction that comes with managing separate registries for different package types.

If you want to go deeper, the related wiki notes on GitHub Overview and GitHub Actions are worth checking out — they’ll give you the broader picture of how all these pieces connect.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? GitHub Pages.

So what exactly is GitHub Pages? Put simply, it’s a feature built right into GitHub that lets you host a static website directly from one of your repositories. You don’t need a separate server, you don’t need to manage hosting accounts, and you don’t need to worry about uptime. GitHub handles all of that for you. It’s particularly well suited for project documentation, development blogs, and public portfolios.

Let’s start with the concept of a source. When you set up GitHub Pages, you tell GitHub where to find your website content. You have a few options here. You can point it at a folder called docs inside your main branch, you can use your main branch directly, or you can use a dedicated branch called gh-pages. Whichever you choose, that’s where GitHub looks when it builds your site.

Now, speaking of building, GitHub Pages has a built-in static site generator called Jekyll. Jekyll is what takes your Markdown files and turns them into proper HTML pages. So if you’re writing documentation in Markdown, you don’t have to manually convert anything. You just write your content, push it to your repository, and Jekyll does the rest. You can also skip Jekyll entirely if you prefer to write your own HTML directly.

One of the nicest things about GitHub Pages is that deployment is fully automatic. Every time you push an update to your source branch, GitHub picks it up and rebuilds your site. You do need to factor in a short wait though. Build times typically run somewhere between one and five minutes, so don’t expect changes to appear instantly. Give it a few minutes and then refresh.

Let’s talk about your web address. By default, your site will be available at a github dot io URL based on your username and repository name. But you can also connect a custom domain if you want something more professional. To do that, you point your domain’s DNS records to GitHub Pages’ IP addresses, then configure the custom domain inside your repository settings. Once that’s done, your site is reachable at whatever domain you’ve set up. And on the security side, GitHub Pages automatically provides SSL certificates for github dot io domains, so you get HTTPS without any extra setup.

For NZRT specifically, GitHub Pages opens up some interesting possibilities. There are three potential sites worth thinking about. First, an API documentation site, which would sit at api dot nzrt dot io and could be auto-generated directly from the codebase. Second, an internal docs and guides site at docs dot nzrt dot io. And third, a development blog at blog dot nzrt dot io. All three of these could be maintained as GitHub repositories and deployed automatically whenever content is updated.

So how do you actually get started? There are five steps. First, you go into your repository’s settings on GitHub and enable the GitHub Pages feature. Second, you select your source, so that’s either your main branch with a docs folder, or the gh-pages branch. Third, you either pick one of GitHub’s built-in themes or supply your own custom HTML. Fourth, once it’s live, you access it at the github dot io URL that GitHub assigns you, or at your custom domain if you’ve set one up. And fifth, from that point on, any time you push a change to your source branch, the site redeploys automatically. You don’t need to do anything else.

That’s the core of GitHub Pages. It’s a lightweight, low-maintenance way to get a professional-looking static site live quickly, backed by the same version control workflow you’re already using for your code. For a consultancy like NZRT, it makes a lot of sense as a way to publish API docs or internal guides without adding another tool to the stack.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Issues & Projects.

If you’ve ever wanted a way to track bugs, plan features, and keep your development work organised in one place, GitHub Issues and Projects are exactly what you need. Let’s walk through how they work and how NZRT uses them day to day.

So, what is a GitHub Issue? Think of it as a conversation-backed task card. You create one with a title, a description, and a few extra details, and from that point on it becomes the single place where everything related to that task lives. Issues come in a few flavours at NZRT. You might open one for a bug someone found, a new feature the team wants to build, or a piece of documentation that needs writing. The type of issue is communicated through labels. Labels are just tags you attach to an issue to categorise it. You might have labels for priority, for which system is affected, for which team owns it, or for where it sits in the process.

Alongside labels, you have milestones. A milestone groups a set of issues together under a shared goal, like a release or a sprint. When you look at a milestone, you can see at a glance how many issues are closed versus still open, which gives you a quick health check on whether you’re on track. Then there are assignees, which is simply the person or people responsible for getting that issue done.

Now, one of the most useful things you can do with issues is link them directly to your code. When you’re writing a commit message or describing a pull request, you can reference an issue by its number, and if you use the word “Closes” before that number, GitHub will automatically close the issue the moment that pull request is merged. This keeps your board clean without any manual housekeeping.

To make sure issues are reported consistently, NZRT uses issue templates. Templates are pre-filled forms that guide whoever is opening the issue through what information to include. Let’s look at the two main ones.

The bug report template asks you to fill in four things. First, a brief description of what the bug is. Second, the steps to reproduce it, written out as a numbered sequence so someone else can follow along and see the same problem. Third, what you expected to happen, and fourth, what actually happened instead. There’s also a section for environment details, things like which browser you’re using, which version of PHP is running, what your Laragon environment looks like, and which versions of WordPress or Dolibarr are involved. That context is often what makes the difference between a bug that gets fixed quickly and one that takes days to pin down.

The feature request template is a bit different. It starts with a description of the feature itself, then asks you to explain the use case, meaning why this feature is actually needed and what problem it solves. Finally, there’s an acceptance criteria section where you list out the specific conditions that need to be true for the feature to be considered complete. This is really valuable because it means everyone, developers, testers, and stakeholders, agrees upfront on what done actually looks like.

Now let’s talk about GitHub Projects. Where issues are the individual task cards, a Project is the board that holds them all. NZRT uses a board called the Dolibarr-Custom Board, and it’s organised into six columns that represent the life of a piece of work from start to finish. Something lands in Backlog when it’s identified but not yet started. It moves to Design when it’s in the design review stage. Once someone picks it up and starts building, it moves to Development. From there it goes to Testing, which is your QA phase. Once testing passes, it moves to Deployment, meaning it’s ready to go live. And finally, when it’s out in the world, it lands in Done.

Projects also support automation, so you can set rules that move cards between columns automatically based on events, like an issue being closed or a pull request being merged. That saves a lot of manual drag-and-drop work and keeps the board accurate without relying on everyone to remember to update it.

If you want to dig deeper into the GitHub ecosystem, this topic connects closely with the GitHub Overview, Pull Requests, and Collaboration Overview pages in the wiki. Those will give you more context on how issues and projects fit into the wider workflow of code review and team collaboration at NZRT.

In short, Issues give you a structured, consistent way to capture and track work, and Projects give you the visual layer to see how all that work is progressing. Together they make it a lot easier to stay on top of what’s happening across your repositories without things slipping through the cracks.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Pull Requests.

If you’ve ever worked on a codebase with other developers, you’ve probably come across pull requests. But what exactly are they, and how do they work at NZRT? Let’s walk through everything you need to know.

A pull request — or PR for short — is the main way code changes get reviewed and merged into a shared codebase on GitHub. When you’ve been working on a feature or a fix in your own branch, a pull request is how you say “hey, I’ve got some changes here — can someone check them over before we bring them in?” It creates a structured, documented process around that conversation.

When you open a PR, a few things happen automatically. First, GitHub shows a visual diff — that’s a line-by-line comparison of everything you’ve changed. Anyone reviewing can see exactly what was added, removed, or modified. Second, all the commits you made on your feature branch are listed, so reviewers can follow the history of your work. Third, GitHub Actions kicks off — those are automated workflows that run checks like linting, testing, and security scans. These have to pass before the PR can be merged.

Then comes the human part. One or two of your peers — depending on how the repository is set up — will review your code. They can leave comments, ask questions, or request changes. If changes are needed, you push additional commits to address the feedback, and those appear in the PR automatically. Once a reviewer is satisfied, they approve, and a maintainer can merge it in.

Let’s talk about how NZRT specifically handles this. It follows a ten-step flow. You start by creating a feature branch with a descriptive name. You make your changes and commit them with clear messages. Then you push that branch up to GitHub and open the pull request with a title and description. You wait for GitHub Actions to pass — that covers linting, testing, and a security scan. Then you request a review from one or two developers. You address any feedback, push more commits if needed, get an approval, and finally a maintainer merges the PR — usually using a squash merge into the develop branch. After that, the branch is automatically deleted, which keeps things tidy.

Now let’s cover PR title format. The title follows a short, structured pattern. You start with a type — for example, feat for a new feature, fix for a bug fix, docs for documentation, style for formatting changes, refactor for restructuring code, perf for performance improvements, test for anything test-related, or chore for maintenance tasks. After the type, you put the scope in parentheses — that’s the area of the codebase you’re touching, such as dolibarr, wp-sync, or scripts. Then a colon, followed by a brief description. So as a spoken example, a PR adding a product comparison widget to the WordPress sync area would read something like: feat, wp-sync scope, add product comparison widget.

PR descriptions follow a standard template with four sections. The first is a plain description of what the PR does. The second links to a related issue — if the work closes a tracked issue, you reference it there. The third section covers testing — you explain how someone can verify the changes work correctly. And the fourth is a checklist: does the code follow the style guide, were tests added or updated, was documentation updated, and are there any breaking changes? Having this template means every PR carries the same core information, making review faster and more consistent.

One more thing worth knowing: NZRT supports draft PRs. If you’re still working on something and not ready for review, you can open it as a draft. That signals to the team it’s a work in progress, so nobody jumps in to review before you’re ready.

There are also three ways a PR can actually be merged. A merge commit preserves all your individual commits as-is. A squash merge combines everything into one clean commit — this is the most common approach at NZRT. And a rebase replays your commits on top of the target branch. Each repository can be configured to support one or more of these strategies depending on what works best for that codebase.

Pull requests aren’t just a gate before merging — they’re a collaboration tool. They create a record of why changes were made, who approved them, and what feedback was exchanged. Over time, that history becomes genuinely valuable for anyone working in the same codebase.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📦 Repositories.

So let’s start with the basics. A GitHub repository is essentially a project container. Think of it as a single organised folder that holds everything related to a project — your code, your documentation, your issue tracker, and the full history of every change ever made. Whether you’re building a web app, managing config files, or storing deployment scripts, the repository is where it all lives.

Now, repositories come with a lot of settings, and understanding those settings is really what separates a well-managed project from a chaotic one. Let’s walk through the key concepts you need to know.

First up is visibility. A repository is either public or private. Public means anyone on the internet can view it — that’s typical for open source projects. Private means only people you’ve explicitly invited can see it. At NZRT, most repositories are private, which makes sense for business tooling and client work.

Next is the default branch. This is the branch that GitHub treats as the source of truth for the project. You’ll often see it called main or develop. It’s also usually the branch that gets deployed, so it matters a lot. Whatever goes into the default branch is what ends up in production.

Then there’s branch protection. This is a set of rules you apply to important branches — usually the default branch — to stop people from accidentally pushing directly to it. You might require that all changes come in through a pull request, that at least one other person reviews and approves that pull request, and that any automated checks or tests pass before the merge goes through. Branch protection is one of those things that feels like overhead until the day it saves you from a very bad situation.

Moving on — collaborators and teams. Collaborators are individual users you’ve given explicit access to a repository. There are five permission levels to know about. Pull access means someone can read and clone the repo. Triage lets them manage issues and pull requests. Write means they can push code. Maintain gives broader project management control. And Admin is full control — settings, access, the works. Teams work similarly, but instead of assigning permissions to individuals one by one, you group users into a team and assign permissions to the whole group. Much easier to manage at scale.

You should also know about the README file. When someone lands on your repository’s home page on GitHub, the first thing they see is the README. It’s your project’s front door — it should explain what the project is, how to set it up, and how to use it. A good README saves everyone time.

And finally, the license. If your repository is public and you want to let others use your code, you need a license. The most common ones at NZRT are MIT, Apache, and GPL. Each has different rules about how people can use, modify, and distribute your work. Without a license, legally speaking, no one has permission to use your code at all.

Now let’s look at a real example from NZRT. There’s a repository called Dolibarr-Custom. It’s private, which makes sense because it holds ERP customisations and modules — internal business logic you wouldn’t want exposed publicly. The default branch is main, and the main branch has protection rules in place: you need at least one review before anything merges, and all status checks must pass. Two collaborators are set up — fin with Maintain access, and xc with Admin access.

If you’re ever setting up a new repository at NZRT, there’s a handy checklist to work through. You want to confirm the visibility is correct, the default branch is set, and branch protection is enabled. Make sure collaborators are invited with the right permission level — not too much, not too little. Set up any webhooks you need for notifications. Add secrets for deployments so credentials never end up in the codebase. Write a README, add a license if it’s open source, and configure a gitignore file so the right files get excluded from version control. And if the project needs a public-facing site, consider whether GitHub Pages should be enabled.

If you want to go deeper, the related wiki notes on GitHub Overview, Branch Protection, and Secrets and Tokens are good next reads.

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