Runners & advanced pipelines

Every runs-on: ubuntu-latest you have typed summoned a fresh virtual machine from GitHub's fleet: booted for your job, preloaded with an enormous toolbox — Git, Docker, the Azure CLI, half a dozen language runtimes — used once, and destroyed. You never patched it, never paid its idle hours, and never inherited anything from the previous job, because there was no previous job. That disposability is the quiet security feature of everything you built in the last two classes: a fresh machine has no leftover credentials, no poisoned cache, no drift. For most teams, most of the time, hosted runners are simply the correct answer, and the interesting question is only what they cannot do.

They cannot reach your private network — a hosted runner lives in GitHub's cloud, so the Class Fourteen private endpoint or an internal-only service is invisible to it. They come in fixed shapes, so a build that wants serious cores, unusual memory, or a GPU is out of luck at the standard sizes. They start from a blank slate every time, so a gigantic toolchain must be fetched on every run — that is a speed tax §3 will address. And they are metered: public repositories run free, private ones burn a minutes allowance and then a credit card, with Windows and macOS minutes billed at a multiple of Linux.¹ Those four limits — network, hardware, startup state, and money — are the complete list of reasons to consider the alternative. Everything else is a reason not to.

Self-hosted runner

A machine you own — a VM, a server, a container — running GitHub's runner agent, picking up jobs from your repository. You gain its network position, its hardware, and its persistence; you take on its patching, its scaling, and everything a malicious job could do to it.

A self-hosted runner solves all four limits at once. Put the agent on a VM inside the Campux VNet and the pipeline can reach the private endpoints of Class Fourteen. Choose the hardware and the build gets whatever cores or GPU it needs. The machine persists between jobs, so the toolchain is already there. And your own compute may be cheaper than metered minutes at scale. Teams reach for it for exactly these reasons, and sometimes they are right to.

Now read the bill. That machine is yours: you patch it, monitor it, scale it, and rebuild it when it fills up with the residue of a thousand builds — because unlike a hosted runner, it remembers. Persistence is the feature and the flaw in one property: whatever job ran at nine o'clock leaves files, processes, and possibly credentials on the machine that runs the ten o'clock job. And the sharpest edge has a name in GitHub's own documentation: never attach a self-hosted runner to a public repository. A public repository accepts pull requests from anyone on the internet, a pull request can modify a workflow, and a workflow is a program your runner executes — which chains into "any stranger can run code on a machine inside your network". The hosted runner absorbs that risk by being disposable and GitHub's problem; the self-hosted runner hands it to you whole.²

The decision rule is short: hosted until a named requirement — private network, specific hardware, or minutes-at-scale economics — forces the question, and then self-hosted with the discipline of a production system, because that is what it is. "It would be a bit faster" is not a named requirement; it is how teams acquire an unpatched Linux box with production network access and a job queue anyone in the org can feed.

Two Actions features move files around, and confusing them costs real debugging time. A cache makes the next run faster: dependencies that take minutes to download get stored against a key and restored on the following run. An artifact carries results — within a run between jobs (which, as Drill 02 of Class Twenty-Two taught, are strangers on separate machines), or out of the run to a human who downloads them.

# cache: speed across runs — keyed on the lockfile
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

# artifact: truth within and beyond a run
- uses: actions/upload-artifact@v4
  with:
    name: whatif-report
    path: whatif-output.txt
# ...and in a later job:
- uses: actions/download-artifact@v4
  with:
    name: whatif-report

The key line deserves the attention. hashFiles('package-lock.json') means the cache is valid exactly as long as the dependency list is unchanged — edit the lockfile and the key changes, the old cache misses, and a fresh download rebuilds it. Get the key wrong in the other direction — too static — and you serve stale dependencies forever while wondering why the pipeline disagrees with your laptop. The rule of thumb: cache things you can afford to lose (it is a speed optimisation, and caches are evicted after a week unused), artifact things you need to trust — a compiled template, a what-if report for an approver, test results an auditor might ask for. Cache is speed; artifact is evidence.

The moment Campux has two repositories, the deploy workflow wants to exist twice — and Class Nineteen already taught you what copies do: they drift. The fix is a reusable workflow: a workflow whose trigger is workflow_call, which other workflows invoke like a function, passing inputs and secrets explicitly.

# platform repo: .github/workflows/deploy-bicep.yml
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with: { client-id: '${{ vars.AZURE_CLIENT_ID }}', tenant-id: '${{ vars.AZURE_TENANT_ID }}', subscription-id: '${{ vars.AZURE_SUBSCRIPTION_ID }}' }
      - run: az deployment group create --resource-group rg-campux-${{ inputs.environment }} --template-file infra/main.bicep

# any other repo calls it in three lines:
jobs:
  deploy-nonprod:
    uses: campux/campux-platform/.github/workflows/deploy-bicep.yml@main
    with: { environment: nonprod }

Its smaller sibling is the composite action — a bundle of steps (an action.yml in its own folder or repository) for sequences that repeat inside jobs, like "log in to Azure and select the subscription". The division of labour: composite action for a reusable step sequence, reusable workflow for a whole job with its runner, environment, and gates. Extraction has the same discipline as Bicep modules — do it when the third copy appears, version the shared thing with tags rather than @main once others depend on it, and remember that a shared workflow is now an interface: changing its inputs breaks every caller at once, which is exactly the power and exactly the risk.

Three settings separate pipelines built by professionals from pipelines that merely work. None takes more than two lines, and all three exist because of a failure somebody paid for.

timeout-minutes

The default job timeout is measured in hours. A hung job — a prompt waiting for input that never comes, a network call that never returns — burns paid minutes and blocks the queue the whole time. timeout-minutes: 15 on every job converts a silent all-nighter into a fast, visible failure.

concurrency

Two merges in quick succession mean two deploys running at once — the Terraform lock fight from Class Twenty-One, recreated inside your own pipeline. concurrency: { group: deploy-prod, cancel-in-progress: false } queues them one at a time; for PR validation, cancel-in-progress: true stops wasting minutes checking commits already superseded.

permissions

Every job gets an automatic GITHUB_TOKEN, and its default powers are broader than most jobs need. Declare permissions: contents: read at the top and grant more only where a job earns it — Class Eight's least privilege, applied to the pipeline's own credential.

Boring pipelines are the achievement.

Notice what all three have in common: they cost nothing when things go well and everything happens the day they are missing. That is the character of this whole class — runners, caches, reuse, hygiene — none of it demos well, all of it decides whether the twentieth repository is as safe as the first. A pipeline that is fast, quiet, and identical every time is not a lack of ambition. It is the ambition.³