What GitHub Actions Is

GitHub Actions is event-driven automation that lives inside the repository. Something happens — a push, a pull request, a tag, a cron tick — and GitHub matches that event against the triggers you declared in a YAML file, then spins up a fresh virtual machine to run the steps you wrote. There is no separate CI server to provision, patch, and keep online; the platform owns the VM and the orchestration, and you own the YAML.

The model is worth internalizing before you write a single workflow: repo activity emits events, your on: declarations subscribe to them, and each match queues a run on an ephemeral runner that is destroyed when the run finishes. Everything else — caching, artifacts, matrix builds, reusable actions — is detail layered on top of that one loop.

The Event-Workflow Model

A workflow does nothing until an event it subscribes to is emitted. The on: key is that subscription. When repo activity produces a matching event, GitHub queues a workflow run; when nothing matches, nothing runs and you pay nothing. This is the difference from a polling CI server that wakes on a timer and asks "anything new?" — Actions is pushed the event the instant it happens, so a run is queued within seconds of the commit.

name: CI
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

What GitHub Hosts

GitHub provides the runner VM, the orchestration that schedules and sequences jobs, and the log and artifact storage you read afterward. Public repositories get unlimited runner minutes; private repositories include 2,000 free minutes per month on the standard Linux runner, after which usage bills against the account. The OS multiplier matters: Linux is the baseline, Windows runners bill at roughly 2x, and macOS at roughly 10x, so an idle macOS matrix leg is a real line item.

Because the pipeline is hosted, you are not responsible for the box it runs on. You do not patch the runner OS, scale the fleet, or keep a Jenkins controller alive at 3 a.m. The trade is that you accept GitHub's runner images and their preinstalled toolchain, and you reach for self-hosted runners only when you need hardware or network access the hosted fleet cannot give you.

Ephemeral Execution

Every job runs on a clean VM that is thrown away when the job ends. Nothing survives between runs, and nothing is shared between jobs in the same run, unless you deliberately persist it: the dependency cache, an uploaded artifact, or a small value passed through job outputs. This is the single fact that catches newcomers — a file written by one job is simply not there for the next, because the next job is a different machine.

The upside of throwaway VMs is reproducibility. A green run on a fresh runner means the build works from a clean checkout with no leftover state, which is exactly the property a CI system exists to guarantee.

Where It Lives

Workflows live in .github/workflows/ as *.yml files, versioned alongside the code they build. A file placed anywhere else is silently ignored — there is no error, the workflow simply never runs. Keeping the pipeline in the repo means a change to CI goes through the same pull request, review, and rollback as a change to the application, which is a meaningful improvement over a pipeline configured by clicking through a server UI.

The Marketplace

Steps that say uses: pull in reusable units of automation called actions, published by GitHub, by vendors, and by the community. actions/checkout fetches your code; actions/setup-node installs a Node toolchain; thousands more cover deploys, notifications, and linters. An action runs inside your job with access to your token and secrets, which is why how you reference one — covered later in this chapter — is a security decision, not just a convenience.