GitHub Actions Basics

Course 2 · Ch 8

Writing your first automated workflow — running tests on every push, without lifting a finger

Every chapter so far has been manual — you decide when to test, when to check things work. GitHub Actions automates that: a workflow file describes steps to run automatically whenever something happens in your repo (a push, a PR, a schedule), and GitHub runs them on its own servers, for free on a generous tier for public repos and personal use.

The Core Concepts

📄 Workflow

A YAML file in .github/workflows/ describing what to run and when. A repo can have several, each independent.

⚡ Trigger (on:)

What causes the workflow to run — a push, a PR being opened, a schedule, or several other event types.

🏃 Job

A set of steps that run together on one fresh virtual machine. A workflow can have multiple jobs, which run in parallel by default.

📋 Step

One action within a job — running a command, or using a pre-built "action" someone else published (like checking out your code).

Your First Workflow — Running Tests on Every Push

Create .github/workflows/test.yml in your repository:

name: Run Tests on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm install - run: npm test

Reading it line by line:

on: — runs on every push to main, and on every PR targeting main (catching problems before merge, not just after).
runs-on: ubuntu-latest — GitHub spins up a fresh Ubuntu virtual machine for this job, every single run, with nothing left over from previous runs.
actions/checkout@v4 — a pre-built action (published by GitHub itself) that clones your repo onto that fresh machine. Almost every workflow starts with this step.
actions/setup-node@v4 — another pre-built action, installing the specified Node.js version. Equivalent actions exist for Python, Java, Go, and most other languages.
run: npm install / npm test — ordinary shell commands, exactly as you'd type them locally.

The GitHub Actions Marketplace has a pre-built action for almost everything

Rather than writing raw shell commands for common tasks, search the Marketplace first — deploying to most major hosting providers, sending Slack notifications, running linters, and uploading test coverage reports all have well-maintained existing actions rather than needing custom scripting.

Seeing It Run

Once committed and pushed, the workflow appears under the repository's Actions tab — every run shows live logs, step by step, and a pass/fail result.

🟡 Run Tests — in progress · triggered by push to main

✅ Run Tests — passed in 42s · all checks succeeded

❌ Run Tests — failed in 18s · npm test exited with code 1

The same result also shows directly on a PR's page as a status check — and if branch protection requires it to pass (Course 3, Chapter 6), a red ❌ here physically blocks the merge button until fixed.

A Second, Equally Common Workflow — Linting

Running a linter automatically catches the kind of style/consistency issues Chapter 7 flagged as not worth a human reviewer's time — letting Actions enforce that instead.

name: Lint on: [push, pull_request] jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 - run: npm install - run: npm run lint

A failing workflow doesn't undo anything — it just reports

GitHub Actions never blocks a push or silently reverts anything on its own; it only runs your defined steps and reports pass/fail. The actual enforcement (blocking a merge on failure) is a separate setting in branch protection rules — without that configured, a failing workflow is informational only.

Command Reference — Concepts, Not Shell Commands

YAML key	What it does
on:	Defines what event(s) trigger the workflow
jobs:	One or more independent sets of steps, run in parallel by default
runs-on:	Which virtual machine OS/image the job runs on
steps:	The ordered list of actions/commands within a job
uses:	Runs a pre-built action from the Marketplace or another repo
run:	Executes a raw shell command directly

Chapter 8 Quick Reference

Workflow files live in .github/workflows/, written in YAML
on: defines the trigger (push, pull_request, schedule, and others)
jobs → steps — each job runs on a fresh VM; steps run in order within it
uses: runs a pre-built Marketplace action; run: runs a raw shell command
actions/checkout@v4 is the near-universal first step — clones your repo onto the runner
Results appear on the Actions tab and directly on PRs as status checks
A failing workflow only reports — branch protection (Course 3, Ch6) is what actually enforces it blocking a merge
Next chapter (Scenario): multiple users on the same branch — diverged history, force-push dangers, and branch protection rules