What CI is and is not — automation, not gatekeeping

Continuous integration is automated execution against a commit. That is the whole sentence. A CI system watches a repository for events (pushes, pull requests, schedules), checks out the commit into a runner, runs the commands the pipeline defines, and reports back a pass or fail. It is not a reviewer, not a policy engine, and not a guarantee that the change is safe to ship. The most common production mistake this part of the course has to undo is the belief that “CI was green” is evidence that the change is correct. CI is automation. Gatekeeping is a separate, layered mechanism that may use CI’s output but is not part of CI.

What CI is

CI is a system that performs three mechanical acts:

flowchart LR
    A["Git event\n(push, PR, schedule)"] --> B["Runner checks out commit"]
    B --> C["Pipeline executes steps"]
    C --> D{"Result"}
    D -->|pass| E["Commit status: success"]
    D -->|fail| F["Commit status: failure"]

1. It receives a trigger. A push to a branch, the opening of a pull request, a tag push, or a scheduled cron fires the pipeline. The trigger is a piece of Git metadata: branch name, ref, commit SHA, author, message.
2. It checks out the commit into a runner. The runner is a fresh or persistent execution environment, fetched from the forge (covered in lesson XXXVII-03).
3. It runs the steps defined in the pipeline file and reports a binary outcome. The pipeline file is plain text in the repository. The runner executes it and returns success, failure, or cancelled. The forge records the result against the commit SHA.

That is the entire mechanism. Everything CI appears to do - test, build, lint, scan, sign, deploy - is a step the pipeline file chose to invoke. CI is the executor; the pipeline is the recipe.

What CI is not

flowchart TB
    CI["CI\n(automation)"]
    Gate["Gatekeeping\n(branch protection,\nrequired reviewers,\nsigned commits,\npolicy controllers)"]
    Review["Code review\n(humans +\nCODEOWNERS)"]
    Audit["Audit and provenance\n(signed tags,\nSBOM,\nattestations)"]

    CI -.uses output of.-> Gate
    CI -.does not replace.-> Review
    CI -.does not replace.-> Audit

CI is not any of the following, despite teams routinely treating it as if it were:

• Not a reviewer. CI does not read the diff for correctness, design, or intent. A green pipeline does not mean the change does what the author claims it does.
• Not a gate. CI does not prevent a merge. Branch protection prevents a merge. CI’s output is one input to branch protection; it is not the gate itself.
• Not a policy engine. OPA, Conftest, signed-commit enforcement, and CODEOWNERS are policy mechanisms. CI may run them, but the policy lives in those systems.
• Not a guarantee of safety. A green CI run on a runner whose secrets are stale, a dependency that was compromised upstream, or a Terraform plan that was reviewed by no human is a green CI run that ships a bad change.

The execution contract

What CI can offer is bounded:

• It runs the pipeline against the exact commit SHA. The reproducibility property of Git carries through: given the commit and the pipeline file, the runner reproduces the same execution.
• It reports a binary outcome. Pass, fail, cancelled, skipped. No judgement.
• It publishes an artefact bound to the commit. A built container, a Terraform plan file, an SBOM - each is a blob whose identity is the SHA, and whose provenance is the CI run URL.

What CI cannot offer, structurally:

• Correctness of intent. The pipeline ran what it was told to run. Whether the change does what the author intended is a human question.
• Trust in the runner. If the runner is compromised, the green result is a lie.
• Trust in the dependencies. If the dependency tree was poisoned upstream, CI faithfully built a poisoned artefact.
• Policy enforcement. CI is the executor of policy steps, not the policy.

Production discipline

1. Separate the layers in your mental model. CI executes. Branch protection blocks. Reviewers review. Policy engines enforce. Treat each as an independent mechanism that may fail independently.
2. Audit trail beats green status. A change that was reviewed, signed, built by CI, and deployed via GitOps has an audit trail. A change that was merely green has a checkbox.
3. “CI was green” never appears in a postmortem as the sole justification for a change. It appears alongside the review link, the policy check, and the deploy identity.

Cross-course references

• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) treats CI as the executor for the package build; the policy layer is apt/dnf repository signing.
• Ansible for Production Sysadmins - Part XXXVII (RepoArch) treats CI as the executor for the playbook lint and ansible-lint, not as the gatekeeper for production runs.
• Terraform for Production Sysadmins - Parts IX-XII (State) cover the same separation: CI runs terraform plan, policy engines constrain it, humans approve it.

Quiz