6.2.2. Scaling and Optimizing Workflows
💡 First Principle: The cheapest job is the one that never runs — so optimization starts by eliminating work (filters, conditionals, concurrency cancellation), then parallelizing what remains, and only then makes individual jobs faster.
Eliminate. Path filters (paths-ignore: ['**.md', 'docs/**']) stop documentation edits from triggering full builds. concurrency with cancel-in-progress: true keyed on ${{ github.workflow }}-${{ github.ref }} cancels superseded PR runs — usually the largest single saving on an active repository. Job-level if: conditions skip work that can't matter (if: github.event_name != 'pull_request' || !contains(github.event.pull_request.labels.*.name, 'skip-ci')). And path-filtering within a workflow, via a change-detection job that emits a matrix of affected packages (2.2.4), turns a monorepo's every-push full build into a targeted one.
Parallelize. Split long serial jobs into independent ones that run concurrently, letting needs: express only the real dependencies — the fan-out/fan-in shape from 2.2. Shard test suites across a matrix so wall-clock time drops even though total minutes stay similar (worth it for feedback speed, not for billing). Tune max-parallel when external services or self-hosted capacity are the constraint.
Accelerate. Cache dependencies (6.2.1). Choose the right runner: larger runners cost more per minute but can reduce wall-clock time enough to pay for themselves on CPU-bound builds, while self-hosted runners with warm caches and preinstalled toolchains eliminate setup entirely. Use timeout-minutes so hung jobs fail in ten minutes rather than burning the six-hour default. And prefer prebuilt container images over building one per run (5.1.1).
For fleets, scale with ARC (3.2.1) so self-hosted capacity tracks demand instead of sitting idle, and monitor with the organization's Actions usage metrics and the workflow-run API (4.2.1) to find the workflows actually consuming the budget — optimization without measurement usually targets the wrong pipeline.
⚠️ Exam Trap: cancel-in-progress: true is right for PR validation and wrong for deployments — cancelling a half-finished production deploy can leave an inconsistent state. For deploys, use a concurrency group without cancellation so runs queue in order.
Reflection Question: A monorepo runs a 30-minute full build on every push, including README edits, and PR branches often have three superseded runs in flight. Name the two changes that address most of the waste, and say which one you'd ship first and why.
