Noor Al-Rashid

My test for a pipeline is whether a person who did not write it can tell from the failure output what to do next. Most cannot. A build should fail for one reason at a time. A pipeline that runs linting, tests and build in parallel and reports one red line gives no indication which stage caused it, and the fix is to make each stage report its own status and to fail the run at the first failure rather than after all of them have finished. Caching is the main lever on speed, and the main source of a wrong answer. A cache key has to include everything the output depends on, so a dependency lockfile and a compiler version both belong in it. A key that misses a dependency version produces a build that uses the previous set, which is faster and wrong. Matrix builds run the same job across versions, operating systems or platforms, and the results need to be aggregated with a rule for which failure counts. Failing on the first matrix entry that breaks is usually the wrong choice for a compatibility matrix. Secrets belong in the platform's secret store and are masked in logs, and masking is a display feature rather than a protection one. A value echoed into a log can leak even when masked, because masking matches the value and a transformed copy does not match. I also cover the two things that make a pipeline reliable: pinning the runner, and keeping the pipeline definition in the repository rather than in a settings screen.