Continuous Integration Patterns for Build, Test, Lint, and Coverage: Core Concepts and Mental Model

1. The practical problem: one opaque script hides several different questions

A workflow that runs ./ci.sh and reports one red or green result can be useful, but it is weak operational evidence. A red result does not immediately tell a reviewer whether dependency resolution failed, lint rejected the source, the code did not build, a unit test failed, coverage missed policy, or the runner/toolchain itself drifted.

Chapter 24 treats CI as a chain of separately observable claims. Each claim is tied to the same event-selected revision and produces evidence that can survive long enough to diagnose the failure. The final merge decision is then an aggregation of those claims, not a substitute for them.

2. Mental model: exact revision in, independent claims out

Read the model from top to bottom. GitHub selects a workflow revision for an event. The checkout must resolve to the intended source SHA. Toolchain and dependency inputs are then established. Lint, build and test/coverage checks each answer a different question. Their logs and artifacts feed a stable aggregate check that branch protection can require.

flowchart TD
  A[Event + workflow revision] --> B[Checkout exact GITHUB_SHA]
  B --> C[Toolchain + locked dependency inputs]
  C --> D[Lint evidence]
  C --> E[Build evidence]
  E --> F[Test + coverage evidence]
  D --> G[Stable aggregate CI check]
  F --> G
  E --> G
  G --> H[Branch / ruleset merge decision]
  C -. optional speed .-> I[(Actions cache)]
  D -. retained evidence .-> J[(Artifact service)]
  F -. retained evidence .-> J

The dashed arrows are intentionally not correctness arrows. A cache accelerates dependency work; it does not authorize dependency versions. An artifact preserves evidence; it does not make the check successful.

3. Define the state before CI changes it

4. Read-only inspection before execution

Before changing CI, inspect what revision and tools you intend to validate. Locally, the following commands are non-destructive. In a workflow, record the same information into the job summary or a small evidence file.

git status --short
git rev-parse HEAD
git show -s --format='%H %cI %s' HEAD
sha256sum requirements-dev.txt
python --version
python -m pip --version

Inside Actions, compare git rev-parse HEAD with GITHUB_SHA. For pull_request, remember that the default event SHA usually identifies the test merge commit, while github.event.pull_request.head.sha identifies the contributor head. Decide which hypothesis you are testing and record both when the distinction matters.

5. Dependency, lint, build, test and coverage are separate claims

6. Cache is a performance hint, never the source of truth

A cache entry is mutable service-side state keyed by workflow-controlled text and cache version. GitHub first looks for an exact key match and can then restore prefix/restore-key matches. An exact hit is observable through cache-hit == 'true'; a miss is not an error if dependency installation can still succeed from authoritative inputs.

- id: pip-cache
  uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-py313-pip-${{ hashFiles('requirements-dev.txt') }}

The cache path contains downloaded package material, not the authoritative dependency declaration. The next step still runs the installer from requirements-dev.txt and checks the resulting environment.

7. A GitHub Actions job is a check; merge policy is another layer

GitHub Actions jobs create Checks. Branch protection or rulesets can require selected check names before merge. Required status checks must be satisfied on the latest relevant commit, and the required name should be intentionally stable. If a workflow uses path filters that skip the entire required workflow, the pull request can wait forever for a check that was never created.

A useful pattern is to keep descriptive internal jobs—Dependencies, Lint, Build, Tests + coverage—and expose one stable final job such as CI required. That final job runs with if: always(), inspects all upstream conclusions, and fails if any required claim failed or was unexpectedly skipped.

8. Determinism has several inputs, not one switch

• Source: validate the event-selected exact SHA and do not silently fetch a newer branch tip midway.
• Workflow/actions: preserve workflow revision and pin external actions to full commit SHAs.
• Toolchain: request Python 3.13 explicitly instead of relying on whatever python the image currently exposes.
• Dependencies: pin or lock package inputs; for stronger guarantees use ecosystem lock/hash mechanisms.
• Environment: record runner OS/image metadata because hosted images evolve.
• Evidence: retain run ID, attempt, reports and artifact identity so a rerun cannot erase the first observation.

9. Common wrong models

10. What Chapter 24 adds to the operating model

Earlier chapters established revisions, runners, caching, artifacts, permissions and provenance. Chapter 24 composes those primitives into a CI decision system: exact source enters; independent, inspectable claims are produced; a stable aggregate check turns those claims into merge policy.

11. Lesson summary

Deterministic CI is not one command and not one green icon. It is a revision-bound chain whose dependency, lint, build, test and coverage claims remain distinguishable, whose speed optimizations cannot alter correctness, and whose final required check can be traced back to preserved evidence.

Knowledge check

Official references and version notes

• Workflow syntax — Current workflow/job/step, permissions, needs and condition syntax.
• Dependency caching — Current cache matching, cache-hit semantics, security restrictions and eviction behavior.
• Workflow commands — Native annotations, outputs, summaries and runner communication.
• Status checks — How GitHub Actions jobs become checks and how conclusions affect merge policy.
• Troubleshoot required checks — Latest-SHA requirements, skipped checks and merge-queue considerations.
• actions/setup-python v7.0.0 — Immutable action revision used in the labs.
• actions/cache v6.1.0 — Immutable cache action revision used in the labs.
• actions/upload-artifact v7.0.1 — Immutable artifact action revision used in the labs.