Welcome to the NZRT Wiki Podcast. Today we’re looking at ⚙️ GitHub Actions.

So what is GitHub Actions? Put simply, it’s the built-in automation platform that lives right inside GitHub. When you push code, open a pull request, cut a release, or even just trigger something manually, GitHub Actions can spring into life and do things for you automatically. We’re talking running tests, checking code quality, building your project, and deploying it to a server — all without you having to lift a finger after the initial setup. At NZRT, we use it across our repositories to keep things consistent and reduce the risk of human error slipping into production.

Let’s walk through the core concepts you need to understand before diving into any of this.

First, there’s the workflow. A workflow is a YAML configuration file that you place inside a special folder in your repository — specifically a folder called dot-github, then workflows inside that. Each file in there defines a piece of automation: what triggers it, what it does, and how it does it.

Speaking of triggers — those are the events that kick a workflow off. You can trigger on a push to a branch, on a pull request being opened, on a schedule like a nightly cron job, on a release being published, or manually via something called a workflow dispatch. That last one is useful when you want a button you can press yourself from the GitHub interface.

Inside a workflow, you have jobs. Jobs are the big chunks of work. By default they run in parallel, but you can chain them so one waits for another to finish. Inside each job, you have steps — these are the individual commands or actions that run in sequence. Think of a job as a recipe, and the steps as each line in that recipe.

Now, actions themselves — with a lowercase a — are reusable blocks of code you can drop into your steps. A huge library of these exists on the GitHub Marketplace. Instead of writing a script to install a specific version of PHP or Node, you just pull in an action someone else has already written and maintained. It saves a lot of time.

Jobs run on runners. A runner is basically a server — GitHub provides hosted ones running Ubuntu, Windows, or macOS, or you can bring your own self-hosted runner if you need more control or specific hardware.

Two more important concepts: artifacts and secrets. Artifacts are outputs from your build — compiled files, test reports, things like that — which you can save and either download later or pass between jobs. Secrets are encrypted environment variables where you store sensitive things like SSH keys, API tokens, and passwords. You configure these in your repository settings, and then reference them safely inside your workflows without ever exposing the actual values in your code.

Now let’s look at two real examples from NZRT’s own workflows.

The first is a PHP lint check that runs on every pull request. When someone opens a pull request, GitHub spins up a fresh Ubuntu server, checks out the code from the repository, installs PHP version 8.1, and then runs a syntax check across all PHP files in the source folder. If any file has a syntax error, the job fails and the pull request gets flagged. This is a simple but powerful quality gate — it stops broken PHP from ever making it into the main branch through a pull request.

The second example is a deployment workflow that fires when a release is published. Again it starts on Ubuntu, checks out the code, and then runs a deployment step. That step does a few things in sequence: it creates an SSH configuration directory, writes a private deploy key — pulled securely from GitHub Secrets, so it’s never visible in the code — into a key file, locks down the file permissions on that key so SSH will accept it, and then connects to the production server via SSH. Once connected, it navigates to the Dolibarr custom code directory on that server and pulls the latest changes from the main branch. So publishing a release in GitHub automatically ships the code to production. Clean, auditable, and no manual SSH session required.

Those two examples give you a good feel for the range GitHub Actions covers — from lightweight code checks all the way through to full deployments. The same mental model applies regardless of complexity: define your trigger, define your jobs, break each job into steps, and use secrets to handle anything sensitive.

If you want to go deeper, the NZRT wiki has related notes on GitHub Actions Workflows, Automated Testing, and Deployment Pipelines — worth a read once you’ve got the fundamentals down.

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