Project challenges / verified progress
Beacon: ship it without fear

The engineering notebook

Make checks enforceable

How does the first GitHub Actions workflow prove Beacon still builds?

Loading statusStage 2 of 9

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Trust the path

Step 01 of 06

Learn the concept

GitHub Actions is a clean machine receiving an event and running steps. That plainness is the point. If Beacon only works on your laptop, the laptop is part of the product and nobody ordered that dependency.

ONE EVENT MANY JOBSpush or PRevent starts runvetstatic mistakesgo vettestrace detector on-racebuildbinary compileslinux amd64
A trigger fans out into independent jobs. Matrix builds are the same idea with variables: describe the job once, then evaluate it for each Go version.
Step 01

The ideas this is made of

The runner starts clean

A hosted runner is created for a job and thrown away after it finishes. It does not have your aliases, uncommitted files or module cache unless you ask for one. This is why CI catches 'works on my machine' bugs.

Events decide when evidence is collected

pull_request checks proposed code before it enters the protected branch. push checks the branch after merge or direct update. You want both because they answer different questions about different repository states.

A cache key is a correctness claim

Caching Go modules saves time, but only when keyed by dependency files such as go.sum. A cache keyed only by operating system can restore stale packages and produce builds that are fast, green and wrong.

Required checks make advice enforceable

A green check is decoration until branch protection requires it. Required status checks force the merge button to respect the pipeline and make failures visible as blocked merges, not Slack folklore.

A tiny CI workflow
name: library-ci
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7.0.1
      - uses: actions/setup-go@v7.0.0
        with:
          go-version: '1.25'
          cache: true
      - run: go test ./...

The shape is already complete: event, job, runner, checkout, toolchain, command. Beacon adds vetting, race detection, build output and branch protection.

Events and jobs carry different meaning

ThingExampleQuestion answered

Event

pull_request

Should this change enter?

Job

test

Does evidence pass?

Step

go test -race ./...

What produced it?

Runner

ubuntu-latest

Where did it run?

Matrix

Go versions

Does it hold twice?

What these are called on the job

  • Workflow — A YAML file in .github/workflows/ that declares events and jobs.

  • Runner — The machine that executes a job.

  • Matrix — A job expansion for several variable values.

  • Required check — A branch rule blocking merge until named status checks pass.