Automated checks and builds for a pet project

In plain terms

A robot that runs your tests and checks on every change to the repository. Passed — a green tick appears next to the change. Failed — you find out immediately rather than a week later.

Why bother in a small project

It catches what you forgot. The classic: everything works for you because a library is installed on your machine that you forgot to add to the dependency list. For everyone else the project won't start. A build on a clean machine catches that instantly.

It imposes discipline. A red mark next to your change is unpleasant, so tests get fixed instead of accumulating.

It reads well. A green badge on a repository signals to an employer that this person knows about automation. That's rare in learning projects.

How it works

You place a description file in a particular folder of the repository. In it you state when to run, on what, and what to do.

A file for a Python project:

name: checks

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: ruff check .
      - run: pytest

Read top to bottom: run on pushes and merge requests, take a clean machine, fetch the code, install the language version, install dependencies, check style, run the tests.

That's all. No servers to configure — the platform supplies the machine.

What's worth checking

Tests. The main thing.

Style and obvious errors. A static analyser catches unused variables, misspelled names and the like.

The build. For front-end work: does the project compile at all.

Formatting. If you've agreed a single style, let a robot police it rather than people in review comments.

What not to do at the start

Don't set up automatic deployment straight away. Checks first, deployment later. Otherwise broken code ships itself.

Don't over-complicate. One file, three steps. Version matrices, caching and parallel jobs come later, when there's a real need.

Don't run on a schedule what can run on changes.

Common problems

Works locally, fails in the build. Almost always a forgotten dependency or a file that never reached the repository. That's precisely the value: learning about it before someone else opens your project.

Tests need a database. Platforms can start helper services alongside the job — that's declared in the same file.

Secret keys are required. They live in repository settings and arrive as environment variables. They must never go into the description file.

Slow builds. If every run takes ten minutes, you'll stop waiting. Cache dependency installation.

How long it takes

The first setup takes half an hour to an hour with the documentation open. After that the file moves from project to project almost unchanged.

The return is disproportionately larger: you stop shipping broken code and get into the habit of keeping tests working.