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.