CI/CD Concepts

Investigate the change set before the graph: a wrong or unavailable diff base, a shallow clone with no common ancestor, and a squash or rebase that moved the fork point. Then check for a real dependency edge the graph never had.

Release it as 1.9.4 from a maintenance line cut at the v1.9.3 tag, containing only the fix. Publish it on a separate release channel so 1.x users receive it while 2.x users are not pulled backwards, and land the same fix on the mainline.

A fork pull request is untrusted code, and any credential present in the job's environment is available to it — build scripts, test hooks and dependency install hooks all execute before anyone reviews the diff. Split it: run the untrusted build with no credentials, hand its output to a separate trusted job that never checks out the fork's code.

A fork pull request runs code, and often a pipeline definition, written by someone with no write access. If secrets were injected, a one-line change would print or exfiltrate them. Withholding them breaks checks that need real credentials, which must be restructured rather than re-enabled.

Any pipeline run in that repository can assume the role — including one from a throwaway branch. Anyone able to push a branch and trigger CI can rewrite the pipeline to run arbitrary commands with production credentials, without review.

They control the branch the build checks out, so they control the build scripts, test files and configuration the pipeline invokes — and often the pipeline definition itself. Running the branch's tests is running their code.

An SBOM lists what is inside an artifact; provenance is a signed statement about how the artifact was produced — which builder, which source repository and commit, which parameters. Verification checks that statement against a policy, bound to the artifact's digest.

Separate the control objective from its implementation. The requirement is that someone other than the author authorized the change and that evidence survives; it is not that a person clicks a button per deploy. Peer review bound to the deployed artifact usually satisfies it.

Trust it in proportion to how the edges are derived: enforced declarations earn near-total trust, inferred imports earn conditional trust. Either way run a periodic full build so an escape is bounded by that interval rather than discovered by a customer.

Tier the work by who is waiting for it: fast checks on every proposal update, the full gate where changes land, and slow or drift-detecting suites on a schedule. Each move trades earlier feedback for compute, or compute for later discovery of a failure.

Decide by consumer. Anything other teams resolve through a dependency range gets SemVer plus a written deprecation policy. Anything deployed only by the team that owns it gets a build identifier and continuous release, because a compatibility claim nobody reads is pure ceremony.

Inventory every stored credential, rank by blast radius, and migrate the highest-privilege deploy keys first. Run federation alongside the old key, cut over, then confirm from provider usage data before deleting. Anything without a federation path gets shortened lifetime and tighter scope instead.

Generation keeps the pipeline proportional to the change: a small setup job computes the affected packages and emits a child pipeline containing only those jobs. The cost is that the definition no longer exists in the repository — it is program output, so it is harder to review, reason about and debug.

CalVer encodes when a release was made; SemVer encodes whether it will break you. Choose CalVer for cadence-driven products with support windows and no dependency-resolver consumers — distributions, applications, data snapshots — and accept that the number carries no compatibility signal.

Masking is a literal string replacement on log output: it catches a secret printed verbatim. Anything that changes the bytes — encoding, splitting, trimming — or that leaves the log stream entirely defeats it, so treat it as a backstop, not a control.

A remote cache is content-addressed by a hash of a task's declared inputs, so any machine that computes the same hash reuses the output — across ephemeral runners, branches and developer laptops. It is safe only if nothing outside those declared inputs affects the output.

Instance count only approximates traffic share when balancing happens per request. With long-lived connections, session affinity or client-side balancing, clients are pinned at connect time, so the canary's real share is set by the routing layer — not by arithmetic on instance counts.

Start from the target's deployment record and identify which principal performed the deploy. Either it was the pipeline, and the gate did not apply or did not fail closed, or it was some other identity deploying outside the pipeline entirely — which no in-pipeline gate could ever have stopped.

Grouping runs by a key such as the branch or proposal, and cancelling the older in-flight run when a newer one arrives, keeps at most one active run per key. It cuts queue depth and spend, since only the newest commit's result is usually wanted — but cancelling deploys is unsafe.

When the output is genuinely per-target: platform-specific binaries, store-signed mobile builds, compiled-in tenant branding, or artifacts rebuilt inside an air-gapped boundary. Compensate with reproducible builds, hash comparison, a thin divergent layer, and testing every variant that ships.

Trade idle machine cost against developer wait time, and price both. Measure queue wait separately from job duration, at high percentiles, alongside provisioning latency. Fix slow provisioning before buying warm capacity, then size a minimum pool to absorb the usual arrival burst.

SLSA v1.0's Build track defines three levels: L1 produces provenance, L2 signs it and has a hosted build platform generate it, L3 hardens that platform so build steps cannot forge provenance. Levels apply per artifact and pay nothing unless someone verifies.