Lesson 02 · GitHub platform · actions

Actions Basics

Automation that runs when your repo changes. One YAML file, three nested ideas — workflow, job, step — and you can read or write any basic CI pipeline.

An Action (the workflow, really — "Actions" is GitHub's name for the whole feature) is code that runs on GitHub's own servers in response to something happening in your repo: a push, a PR, a schedule, a manual button click. No servers to manage — you write YAML, GitHub runs it.

The nesting: workflow → job → step

Every workflow file lives at .github/workflows/<name>.yml — that exact folder is how GitHub finds it, nothing to register elsewhere.

name: CI # shown in the Actions tab on: push # the trigger — what starts this workflow jobs: build: # a job = one fresh virtual machine runs-on: ubuntu-latest # which OS image to boot steps: - uses: actions/checkout@v4 # step 1: reuse someone's packaged action - run: echo "hello" # step 2: run a raw shell command
Workflow
The whole file. One repo can have many, each its own trigger and purpose (CI, deploy, nightly cleanup).
on:
The trigger. push, pull_request, schedule (cron), workflow_dispatch (manual "Run workflow" button). Can scope to branches: on: {push: {branches: [main]}}.
jobs:
One or more jobs. Each job = a brand-new, disposable VM. Jobs run in parallel by default, unless you say needs: another job.
runs-on:
Which OS image boots for the job — almost always ubuntu-latest unless you specifically need Windows or macOS.
steps:
Ordered list inside a job. Two flavors: uses: runs someone else's packaged action (from the Marketplace); run: runs a raw shell command. Mix freely.
Why almost every workflow starts with actions/checkout The VM boots empty — it does not have your repo's files. actions/checkout@v4 is the near-universal first step: it clones your repo onto the runner so later steps (run: commands, build tools) have something to work on. Forgetting it is the most common first-workflow bug — every file-based command after it just fails to find anything.

A real, minimal CI workflow for this repo

This workspace has no build step (see CLAUDE.md — static HTML, nothing compiles), so "CI" here means something honest and small: a sanity check that fails loudly if something's actually broken, not a fake green checkmark.

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

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: root index.html exists
        run: test -f index.html

Two triggers at once: every push to main, and every pull request (against any branch) — so a broken PR gets flagged before it merges, not after. test -f is a plain shell check, not a special GitHub thing — anything you could type at a terminal works in a run: step.

Your win — ship a real workflow In this repo: create .github/workflows/ci.yml with the YAML above (or your own small check — e.g. confirm every course's index.html exists). Commit and push to a branch, open a PR, and watch the Checks section at the bottom of the PR run it live. Then check the Actions tab at the repo's top nav — every run, past and present, lives there with full logs per step.

Go deeper

Primary source — read this one: GitHub Docs — Actions Quickstart. Walks the exact workflow → job → step structure with a real example.

Then do it for real: GitHub Skills — Hello GitHub Actions, or the CI workflow you just wrote above.

Reference: reference/ — a workflow-YAML cheat sheet is worth building once a few more triggers/actions get used.

Previous: Lesson 01 — Issues · Next: Lesson 03 — Projects · Index: all lessons

Anything fuzzy? Ask your teacher — the agent in this workspace.