Tag Archives: actions

000GIT, 04 - Workflows & Automation

Github Actions Workflows

Leave a comment

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.

000GIT, 02 - GitHub Features

Github Actions

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.