CI Platforms - GitHub Actions

As we discussed in our introduction to CI, Continuous Integration (CI) and Continuous Deployment (CD) are essential components of modern software development. GitHub Actions excels in these areas, automating the building, testing, and deployment of code changes. Developers can define workflows that automatically trigger these actions whenever code is pushed to a repository, reducing manual intervention and the risk of human error.

As one of the leating CI Platforms - GitHub Actions supports various languages, build environments, production targets and the various automation steps allow developers a huge degree of flexibility in the way they wish to configure their build processes.

Let's take an example from our own experience. We deploy the Ghost Theme used on our own site, and other company's sites for whom we develop. The Ghost CMS platform provides their own

The other great thing about the GitHub Actions workflow is it leverages the Configuration-as-Code (CaC) pattern - the benefits of which you can read about here.

A worked example

Generally we configure our repositories such that once we push to the master, we are expecting this to get deployed. More complex workflows might deploy to a staging and subsequent production environment with for example stage and production branches. The YAML looks like this:

name: Deploy Theme
on:
  push:
    branches:
      - master
      - main
jobs:
  deploy:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v3
      - uses: TryGhost/action-deploy-theme@v1
        with:
          api-url: ${{ secrets.GHOST_ADMIN_API_URL }}
          api-key: ${{ secrets.GHOST_ADMIN_API_KEY }}

Pretty simple to read right? We're telling GitHub to take action on pushes to master or main, and ultimately use the TryGhost/action-deploy-theme@v1 to deploy our theme. This goes through the steps of building, packaging and deploying our theme. Of course, this is pretty much the same for anyone who uses a Ghost theme, so it makes total sense for this to be really simple boiler plate.

Now, you'll know that GitHub is public and we don't want to expose our API url or key secrets to the entire internet, so GitHub provides a secure secret vault for that kind of information to be provided to the pipeline as it runs.

Asthe pipeline runs, we get a wealth of information about the pipeline, which is all updated live:

This pipeline is rather simple, so it contains just one deploy job. However, more complex jobs show various tasks within this view, and any pipelines with test results also capture that information in this view.

There is a lot of granularity and complexity around where the agent activities are run (you can choose to run on GitHub's various agents or self-host an agent on infrastructure of your choice).

GitHub is heavily focussed on the open source community, and this shows in our example here. With minimal effort we were able to pick up a pipeline from another user (i.e. the official TryGhost repositories) and use it in our pipeline straight away.

You can read the documentation for GitHub Actions here.