Runners & advanced pipelines

Every runs-on: ubuntu-latest job starts on a fresh virtual machine from GitHub's fleet. Git, Docker, and common language tools are already installed. GitHub maintains the machine, and the job's files do not remain on it for the next job. That reduces the risk of one job leaving credentials or processes behind. It does not make shared Actions caches safe to trust: a later job can restore cached files, so never put secrets in a cache and treat restored content as untrusted.

A standard hosted runner cannot directly call a private endpoint in your VNet: it has no route there. If your plan supports it, a larger GitHub-hosted runner connected to an Azure VNet can provide that route while GitHub still maintains the runner. Standard runners also offer a limited set of machine sizes. Every new job must obtain its dependencies again unless a cache helps, and usage may incur charges according to the repository, runner, and plan. Compare the actual network, hardware, security, and cost requirements before choosing a runner.¹

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 is a machine you operate with the GitHub runner agent installed. If that machine has a route to a private endpoint, a job on it can call that endpoint. You choose its hardware and installed tools, but you pay for the machine, maintenance, and idle capacity. Compare those costs with a larger VNet-connected hosted runner before assuming self-hosting is cheaper.

Now read the bill. That machine is yours: you patch it, monitor it, scale it, and rebuild it. A persistent runner can carry files, processes, or credentials from one job into the next. Avoid attaching one to a public repository: untrusted pull-request code could run on a machine with access to your network. Private repositories also need review of who can submit code or trigger workflows; "private" alone does not make every job trustworthy.²

One runner rarely stays one runner. The moment two jobs want it at once the second waits, so self-hosted machines are pooled — and a runner group decides which repositories and workflows may draw from a given pool, so the finance team's runner is not quietly borrowed by an experiment in someone's fork. Scaling that pool by hand is a losing game, which is why serious self-hosted setups autoscale: ephemeral, single-use runners registered just in time, torn down after one job, spun up again on demand. GitHub's Actions Runner Controller does exactly this on Kubernetes. Read the shape of that answer twice — the mature fix for self-hosting's persistence problem is to rebuild the statelessness you gave up in §1. When the sophisticated version of a thing reinvents the default you left, the default was usually right for anyone who did not have to leave it.

Start with the standard hosted runner. If a job needs private network access or a different machine size, evaluate an eligible larger hosted runner before operating your own. If self-hosting is necessary, use repository and workflow restrictions, isolation, patching, and preferably single-use machines. Measure actual run time and cost before adding infrastructure just to make a slow build faster.

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: a named file available 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

hashFiles('package-lock.json') changes the cache key when that file changes. A static key can restore outdated dependencies. Use a cache only for files you can recreate, never for secrets; restored content is untrusted. Upload a report as an artifact when another job or person needs that run's output. An artifact is a convenient delivery record, not proof that the file is accurate or tamper-proof. Check its producing workflow and retention settings before treating it as audit evidence. Cache helps speed; artifact carries a result.

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
    permissions:
      contents: read
      id-token: write
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v7
      - uses: azure/login@v2
        with: { client-id: '${{ vars.AZURE_CLIENT_ID }}', tenant-id: '${{ vars.AZURE_TENANT_ID }}', subscription-id: '${{ vars.AZURE_SUBSCRIPTION_ID }}' }
      - env:
          TARGET_ENV: ${{ inputs.environment }}
        run: az deployment group create --resource-group "rg-campux-$TARGET_ENV" --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@<reviewed-commit-sha>
    with: { environment: nonprod }

This is a pattern, not a ready-to-run deployment: replace the commit placeholder with a reviewed SHA, provide the Bicep file and Azure variables, and configure the caller repository's OIDC trust and access to the reusable workflow. actions/checkout in the called workflow checks out the caller repository, so that repository must contain infra/main.bicep. Use a reviewed environment name and configure its approval rules before relying on a gate.

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. Use a composite action for steps inside a job, and a reusable workflow when you need to share jobs, runner selection, or environment gates. For a cross-repository caller, a reviewed commit SHA gives the most stable reference; update it deliberately when the shared workflow changes. A tag can communicate a release, but a mutable tag can change underneath callers.

The storefront has to pass its tests on the Node version running in production today and the one the platform team is about to move everyone to. Writing the test job twice creates copies that can drift. A matrix writes the job once and expands it into one job per combination. They can run concurrently when runners are available, subject to max-parallel.

# one job definition, six actual jobs
strategy:
  fail-fast: false
  max-parallel: 4
  matrix:
    node: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]

Three Node versions times two operating systems is six jobs from nine lines, and the two knobs above are the ones that bite. fail-fast defaults to true, which cancels every sibling the instant one fails — efficient when you only need to know whether anything is broken, actively unhelpful when you need to know which combinations broke, because it hides five answers to save a minute. max-parallel caps how many run at once, which matters most on self-hosted pools with a finite number of machines — an uncapped matrix can swallow the whole fleet and starve every other pipeline. Two refinements earn their place: include adds a single extra combination without multiplying the grid (test one exotic edge, not all of it), and exclude removes a combination that makes no sense. The cost to watch is the obvious one — a matrix multiplies, so a careless third dimension turns six jobs into fifty and your minutes bill with them.

The reusable workflow in §4 already carries the word: environment: ${{ inputs.environment }}. That line is not decoration. A GitHub environment is a named target — nonprod, prod — that you can wrap in protection rules, and a job that references one stops at its gate before the first step runs. The most valuable rule is required reviewers: name one or two people, and a deploy to prod pauses, waits, and does nothing until one of them clicks approve. The Class Twenty-Three point lands here with force — the federated credential is handed to the job only after the yes, so "who can deploy to production" stops being a question about who can push code and becomes a question about who can approve, which is the separation an auditor is actually asking for.³

Two more rules pay their way. A wait timer holds the deploy for a set number of minutes — a deliberately boring pause that lets a bad release be caught before it lands. A deployment branch policy restricts which branches may deploy to the environment at all, so prod can refuse anything that is not main no matter how the workflow is triggered. And environment-scoped secrets mean the production credential physically cannot be read by a job targeting nonprod — the blast radius of a leaked secret shrinks to the one environment that holds it. This is the machinery behind the promise the "On the job" box made two screens up: the risky step waits for a human, and the waiting is configuration, not a convention someone has to remember. Azure Pipelines calls the same idea Environments with approvals and checks (Class Thirty-Nine); the vocabulary differs, the gate is identical, and AZ-400 expects you to recognise it in either dialect.

Reuse has two halves. §4 shared pipeline logic; the other half is sharing code. When the storefront and the platform both need the same validation helpers, the wrong answer is a copied file — Class Nineteen's drift, again — and the right answer is to publish the helpers once as a versioned package that both repositories install like any other dependency. GitHub Packages is the registry sitting next to your repository: it hosts npm, NuGet, Maven, and RubyGems packages, and container images through ghcr.io. A workflow publishes to it with the same GITHUB_TOKEN you have been granting scopes to, this time with permissions: packages: write — least privilege, per Class Eight, applied to the act of publishing.

# illustrative npm publish steps; configure the package registry and authentication first
permissions:
  contents: read
  packages: write
steps:
  - uses: actions/checkout@v7
  - run: npm ci
  - run: npm publish                # after a reviewed version bump

For npm, set the package's publishConfig.registry to https://npm.pkg.github.com and configure a scoped package name plus authenticated npm registry access in the workflow. The steps above omit that setup, so copying them alone will not publish to GitHub Packages. Bump and review the version before the release job; a publish job should not silently create a new version in its checkout.

The version number is the whole discipline, and it has rules. Semantic versioning — MAJOR.MINOR.PATCH — is a promise to the people who install your package: bump the patch for a bug fix that changes nothing they rely on, the minor for a feature that adds without breaking, and the major only when you break something they will have to react to. Consumers pin a range in return — "the current 2.x, and pick up minors and patches automatically" — so a disciplined publisher can ship a fix to forty repositories without a single one editing a file, and an undisciplined one who slips a breaking change into a patch has just detonated all forty at three in the morning. This is the same interface contract §4 drew for reusable workflows, now applied to code: the number is the API, and breaking it quietly is the cardinal sin.

The Azure sibling is Azure Artifacts — feeds that host npm, NuGet, Maven, Python, and universal packages for Azure DevOps pipelines, with upstream sources that proxy the public registries so an outage upstream does not stop your build. GitHub Packages and Azure Artifacts are the same idea in two houses; SemVer is the language both speak, and the reason AZ-400 keeps a section for it. Publishing is where a great many candidates go blank in the interview — they can write a pipeline that deploys, but not one that ships a versioned thing other teams depend on, and the second is the more senior sentence to be able to say.

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. Newer repositories default it to read-only; older ones still hand out write-everything — and either way, an unstated default is a decision someone else made. 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, matrices, caches, reuse, gates, packages, 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.⁴