CI pipelines: test every push

You can test your code by hand before every commit, and you'll forget exactly once, on the Friday afternoon it matters most. Continuous Integration (CI) makes a server do it for you: every time anyone pushes, a fresh machine checks out the code, lints it, tests it and builds it, then reports ✓ or ✗ to everyone. Broken code gets caught minutes after it's written, not weeks later in production.

CI, CD and CD

The order of the stages matters: fail fast. Put quick checks (linting, seconds) before slow ones (tests, builds, minutes), so a typo is reported right away.

A workflow, line by line

GitHub runs every YAML file in .github/workflows/. The practice repo will get this one (a copy is in ~/examples/ci.yml):

name: CI                        # shown in the list of runs

on: [push]                      # WHEN: on every push (also: pull_request, schedule, workflow_dispatch…)

jobs:
  test:                         # a job = one fresh machine
    runs-on: ubuntu-24.04       # WHERE: a GitHub-hosted Ubuntu VM, thrown away afterwards
    steps:                      # WHAT: in order; the first failure stops the job
      - uses: actions/checkout@v4     # a ready-made action: clone the pushed commit

      - name: Lint shell scripts
        run: shellcheck *.sh          # a shell command (bash -e: any error fails the step)

      - name: Run tests
        run: ./test.sh                # exit code 0 = pass, anything else = fail

• Exit codes are everything. CI knows nothing about “tests”. A step passes if its command exits with 0 and fails otherwise. That's why your test script must exit 1 when something is wrong.
• Every run starts clean. Nothing you installed or changed on your own machine exists on the runner. If the tests need a package, the workflow must install it. This is how CI catches “works on my machine”.
• uses: pulls in a reusable action (checkout, set up Python, log in to a registry…). Pin a version (@v4) so it doesn't change under you.

Both families in one pipeline

A matrix runs the same job several times with different settings. Here it runs your tests inside a Rocky container and an Ubuntu one:

jobs:
  test:
    runs-on: ubuntu-24.04
    strategy:
      matrix:
        image: ["rockylinux/rockylinux:9", "ubuntu:24.04"]
    container: ${{ matrix.image }}
    steps:
      - uses: actions/checkout@v4
      - run: ./test.sh

(The practice terminal runs plain steps. Matrices and container: are for the real thing.)

Reading the results from the terminal

GitHub shows runs on the website, and GitHub's own CLI, gh, shows them in the terminal:

gh run list                       # recent runs: ✓ passed, X failed
gh run view                       # the latest run: jobs, steps, and which one failed
gh run view 11493020001 --log-failed    # just the output of the failed step

sudo dnf install epel-release
sudo dnf install gh ShellCheck

sudo apt install gh shellcheck

In the practice terminal, gh is already installed and wired to a git server in /srv/git that behaves like GitHub Actions. On a real machine you'd first run gh auth login.

ShellCheck: a spell-checker for scripts

ShellCheck finds the bugs that bite shell scripts: unquoted variables, a cd that might fail, bash-only syntax in an sh script. Its most famous warning is SC2086:

echo Hello, $name!
            ^---^ SC2086 (info): Double quote to prevent globbing and word splitting.

Unquoted, $name is split into words and globbed: a name like * would turn into a list of files! echo "Hello, $name!" is the fix. ShellCheck is the first step in almost every pipeline that ships shell scripts, and you can run exactly the same command locally before you push.

Other CI systems

The ideas carry over between all of them: a trigger, jobs on clean machines, steps that pass or fail by exit code, and logs to read when they fail.

Practice: red, green, red, green 🚦

~/greeter is a tiny script with tests, already pushed to the git server. Add CI, watch it catch a real bug, fix it, then watch it catch a new one.

Quick check