Continuous Integration

Know what CI will enforce before you ask it to validate your branch.

CI is optimized for signal, not ceremony. Pull requests route work based on changed files and labels, while main, edge, nightly, and release workflows enforce the heavier publication and hardening gates. Run the closest local equivalent first so CI is confirming your work, not discovering it for you.

Diagram

CI and publish flow

Pull requests are change-routed; publish channels add provenance and reproducibility gates before anything is promoted.

Verify

PR-equivalent local gate

bash

make bootstrap
make doctor
make ci-core

Treat this as the default local bar. If this is red, CI is not the right place to learn that first.

Decision matrix

Map CI lanes to local commands

Map CI lanes to local commands.

CI concern	Run locally	Notes
Core PR validation	make ci-core	Covers lint, formatting, tidy, vendor, generated artifacts, tests, docs, Helm, security, fuzz smoke, and config compatibility.
Docs-only changes	make docs-build	Use this when the change is isolated to documentation, routing, or site behavior.
Dependency and license policy	make verify-vendor and make license-check	The repository enforces vendored dependency resolution and shipped-license allowlists through its local and CI artifact checks.
Image and filesystem security scans	make security-ci and make security-scan-built-images	Run these when images, dependencies, or container-facing surfaces changed.
Focused E2E and platform validation	make test-e2e-ci ..., make helm-e2e-smoke, or make test-e2e-existing ...	Use label filters or the existing-cluster path when you need a smaller or platform-specific reproduction.

What CI assumes

CI and release workflows enforce vendored Go dependencies. After dependency changes, rerun make verify-vendor. License verification uses that same vendored view of the dependency graph.

Decision matrix

How routing expands

How routing expands.

Situation	What usually happens	Why it matters
Docs-only or workflow-only pull request	CI skips broad E2E by default and focuses on the relevant smaller lanes.	You avoid paying for cluster work that cannot fail for the files you touched.
PR touches backup, upgrades, security, provisioner, admission, or controller-critical code	Targeted E2E shards expand automatically.	Coverage follows the risk of the changed surface.
Maintainer adds ci:full-e2e	The broader E2E suite runs.	Use this when the change is wide enough that targeted routing is no longer sufficient.
Nightly, edge, or tagged release flow	Publish channels add provenance, reproducibility, and release-oriented hardening gates.	Passing PR CI alone is not enough to publish artifacts.

Inspect

Typical focused E2E reproductions

bash

make test-e2e-ci \
KIND_NODE_IMAGE=kindest/node:v1.34.3 \
E2E_LABEL_FILTER='(((lifecycle && !tls) || manager) && !openshift)' \
E2E_PARALLEL_NODES=1

make helm-e2e-smoke

make fuzz
FUZZ_TARGET_FILTER='FuzzDiscoverConfig|internal/service/upgrade' make fuzz

Use the smallest reproduction that still matches the CI lane you are trying to explain.

After CI parity

Testing strategyGo back one level when you still need to choose the right validation depth before mapping it to a workflow.Release managementMove into release execution, stable-doc snapshot rules, and post-publish verification once the branch is release-ready.Dependency license policyOpen the shipped-license rules when the failing gate is about allowlists rather than code or workflow behavior.