GitHub Actions, decoded line by line

Your first workflow file

GitHub's built-in CI is GitHub Actions. You enable it by committing a YAML file (same format as compose in lesson 5-1) under .github/workflows/ in your repo. That is the entire setup, no server to install.

name: ci
on:
  push:
    branches: [main]
  pull_request:

• name: ci: the label shown in the repo's Actions tab
• on:: the events that trigger this workflow. This one runs on every push to main and on every pull request

A trigger fires, GitHub boots a fresh virtual machine (a runner), and executes your jobs on it. Fresh machine every run is the point: no leftover state, no works-on-my-runner, the lesson 1-1 problem solved by brute force.

Jobs and steps

The rest of the file:

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: pytest

• jobs:: a workflow contains one or more jobs, each on its own runner
• runs-on: ubuntu-latest: which kind of runner VM to use
• steps:: the commands, executed top to bottom, each stopping the job if it exits non-zero (lesson 7-1)
• uses: actions/checkout@v4: a reusable action from the marketplace. This essential one clones your repo onto the runner. Without it the runner is an empty machine
• with:: parameters for an action
• run: pytest: a plain shell command, exactly what you'd type in a terminal

That is the whole vocabulary: events, jobs, steps, uses for shared actions, run for shell.