A CI pipeline with GitHub Actions

GitHub Actions is GitHub's built-in CI service. A workflow is a YAML file in .github/workflows/ in your repository. GitHub starts it on events you choose and runs its jobs on a fresh machine.

The example workflow:

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip
      - name: Install
        run: pip install -r requirements.txt -r requirements-dev.txt
      - name: Scan for secrets
        run: python secret_scan.py $(git ls-files '*.py' '*.yaml' '*.yml' '*.toml')
      - name: Lint and format check
        run: ruff check . && ruff format --check .
      - name: Test
        run: pytest -q

  image:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t ship-it:${{ github.sha }} .

The steps run in order, cheapest first: scan for secrets, check style (ruff is a fast tool for linting, which means spotting likely mistakes, and for formatting), run the tests, and only then build the image. The first red step stops the line, so a quick problem is reported quickly.

On this machine the checks passed: ruff check printed "All checks passed!", ruff format --check said "3 files already formatted", and pytest -q printed 4 passed.

Good CI habits

• Fast. Aim for under five minutes. Cache dependencies (cache: pip).
• Required. In the repository settings, make the checks mandatory before merging to main. This is called branch protection.
• Reproducible. The pipeline installs from the same pinned requirement files you use locally. requirements.txt here pins exact versions.
• Careful with secrets. Give a secret only to the step that needs it. Workflows started by pull requests from forks do not receive secrets, on purpose. Never print them.
• Pin third-party actions. Prefer a full commit hash over a tag like @v4 for actions you do not control, to guard against tampering.
• Fail loudly. A red build that people learn to ignore makes the pipeline worthless.

From CI to CD

Once CI is green on main, a deploy job can push the image to a registry (a store for images) and update the running service. Keep the order: build once, test that exact build, deploy that same image.