Making the Robot Do the Boring Part

There is no configuration screen. GitHub Actions reads .github/workflows/*.yml from your repository — that path, exactly — and any file it finds there is a workflow. Commit one and it is live.

name: CI on:  push:    branches: [main]  pull_request: jobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4       - uses: actions/setup-node@v4        with:          node-version: 22          cache: npm       - run: npm ci      - run: npm run lint      - run: npm run typecheck      - run: npm test

That file is a complete, working continuous integration setup. Every push to main and every pull request now gets a fresh Ubuntu machine that checks out your code, installs Node, installs dependencies, and runs four commands. If any of them exits non-zero, the run fails.

The on block is where most of the design happens, because running the wrong workflow at the wrong time is how teams end up waiting eleven minutes for a documentation typo.

on:  # Only pull requests targeting main, and only when code changes  pull_request:    branches: [main]    paths-ignore: ["docs/**", "**.md"]   # Every night at 03:00 UTC — cron, in UTC, always  schedule:    - cron: "0 3 * * *"   # A button in the Actions tab, with an input  workflow_dispatch:    inputs:      environment:        type: choice        options: [staging, production]   # When a release is published  release:    types: [published]

Two settings are worth adding to almost every workflow. Concurrency cancels the previous run when you push again — otherwise pushing three times in five minutes means three full runs, two of which are already irrelevant. And permissions narrows what the automatic token can do.

concurrency:  group: ${{ github.workflow }}-${{ github.ref }}  cancel-in-progress: true permissions:  contents: read

Each job gets its own clean virtual machine. Nothing is shared between jobs — not the checkout, not the installed dependencies, not the files one of them wrote. Steps within a job share everything, because they are on the same machine.

src/lib/users.ts:14:22 - error TS2532: Object is possibly 'undefined'.

14   return res.body.id;
                ~~~~

Found 1 error in src/lib/users.ts:14

Error: Process completed with exit code 2.

That is why actions/checkout is the first step of nearly every job. The machine starts empty; without it there is no code to run anything against.

Two mechanisms shape how jobs relate to each other:

jobs:  lint:    runs-on: ubuntu-latest    steps: [...]   test:    runs-on: ${{ matrix.os }}    strategy:      fail-fast: false      matrix:        os: [ubuntu-latest, windows-latest]        node: [20, 22]    steps: [...]    # This one job definition produces FOUR parallel runs   deploy:    needs: [lint, test]        # waits for both, and is skipped if either fails    if: github.ref == 'refs/heads/main'    runs-on: ubuntu-latest    steps: [...]

fail-fast: false is worth setting on a matrix. The default cancels every other combination the moment one fails, so you learn that Node 20 broke and not whether Windows also did — which is usually the thing you needed to know.

Every job appears on the pull request as a check, with a tick or a cross and a link to its logs. That is the visible half of Actions and the reason most teams adopt it.

But a red cross on its own blocks nothing. Anyone can merge straight past it. The check only becomes a gate when it is named as required in the branch protection rules — which is the connection between this chapter and the last one.

$ gh run list --limit 5              # recent runs$ gh run watch                       # follow the current one$ gh run view --log-failed           # just the failing step's output$ gh workflow run deploy.yml -f environment=staging   # trigger a workflow_dispatch

A deploy workflow needs credentials, and the workflow file is committed to the repository. Secrets are the way out: encrypted values stored in the repository's settings, injected at run time, and never shown again after you save them.

      - name: Deploy        env:          API_TOKEN: ${{ secrets.DEPLOY_TOKEN }}        run: ./scripts/deploy.sh

$ gh secret set DEPLOY_TOKEN          # prompts, and never echoes$ gh secret list

GitHub masks secret values in logs, so a token that gets printed appears as ***. Treat that as a safety net rather than a guarantee: a value that is transformed before printing — base64-encoded, split, interpolated into a URL — is not recognised and not masked.