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

If you’ve ever pushed code to a GitHub repository and wondered how tests run automatically, or how your changes end up on a server without anyone manually doing it — that’s GitHub Actions at work. At NZRT, we use it across our repositories to handle linting, testing, and deployment in a consistent, automated way.

So let’s start with the basics. A GitHub Actions workflow is a configuration file written in YAML, and it lives inside a folder called dot-github slash workflows in your repository. The structure of one of these files is straightforward. You give the workflow a name, you tell it what events should trigger it — things like a push to a branch, a pull request, or a scheduled time — and then you define one or more jobs. Each job runs on a virtual machine, typically the latest version of Ubuntu, and contains a series of steps that run in order.

Now let’s look at the main workflows NZRT uses.

The first is the deploy workflow for the Dolibarr custom project. This one triggers in two situations: when you push to either the develop or main branches, or when a release is published. It has three jobs that can run depending on the context.

The first job is called lint-and-test, and it runs every time. It sets up a PHP 8.1 environment with the extensions needed for the project, installs dependencies using Composer, then runs three checks in sequence. First it scans every PHP file in the WordPress content folder to make sure the syntax is valid. Then it runs a security scan. Then it runs the full test suite using PHPUnit. If any of those steps fail, the whole workflow stops there.

The second job, deploy to staging, only runs if the branch being pushed is the develop branch, and it only starts if lint-and-test passed. It connects to the staging server over SSH using a deploy key stored as a secret, pulls the latest code, and flushes the WordPress cache. When it’s done — whether it succeeded or failed — it sends a Slack notification with the status, who triggered it, and what repository it was for.

The third job, deploy to production, works differently. It only runs when you push a version tag — something like v one-point-two-point-zero. It uses GitHub’s deployment API to register a formal deployment event, then connects to the production server via SSH, checks out the tagged version, pulls it down, flushes the cache, and exports a database backup before anything changes. After deploying, it runs two health checks against the live site to confirm it’s responding. Then it sends a Slack notification with the version number and status.

The second workflow is the Dolibarr CI workflow. This one runs on every push and every pull request — so it’s always watching. It has two jobs. The first is a linting job that checks your PHP code against the PSR12 coding standard and runs static analysis to catch type errors and other issues before they become bugs. The second job is a test job, and this one spins up an actual MySQL 8 database as part of the runner environment — it even has a health check to make sure the database is ready before the tests start. Then it installs dependencies and runs the test suite against that live database connection.

The third workflow is the NZRT Scripts deploy workflow. This one is simpler. Any time you push to the main branch of the NZRT-Scripts repository, it SSHes into the cPanel server, goes to the scripts folder, pulls the latest code from the main branch, and makes sure all shell scripts are marked as executable. Then it verifies the deploy worked by logging the most recent commit on the server.

Now, all three of these workflows rely on secrets — sensitive values like SSH keys, usernames, and ports that you never want to hard-code into a file. NZRT manages these at the organisation level in GitHub, which means they’re available to every repository without you needing to set them up repo by repo. There are three org-level secrets you need to know about. The deploy key is the SSH private key used to authenticate with the server. The deploy user is the cPanel SSH username. And the deploy port is the port number used for SSH connections. All three are stored in the organisation secrets settings page on GitHub.

If you want to dig deeper, the wiki has related notes on CI CD Overview, Automated Testing, Deployment Pipelines, and the Git Deployment page which covers cPanel-specific git setup.

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