The worst CI outcome is not a failing build.
It is a passing build that did nothing and looked correct.
Here is one way to get there, and it takes a single missing line of YAML.
The setup A pipeline that deploys only what changed.
It diffs against the parent commit, maps changed paths onto folders, and conditions each deployment stage on the result.
The failure Azure DevOps can check out with shallow fetch.
A shallow clone has no parent commit.
So does not error.
It returns nothing.
Nothing changed, therefore nothing needs deploying, therefore every stage skips, therefore the pipeline is green.
Nobody is alerted, because from the outside this is exactly what a run looks like when someone edits a README.
You find out later, when something that was supposed to be in production is not.
The fix is two parts Make the pipeline correct: And make the script refuse to guess: The second part matters more than the first. is one line in a YAML file that someone will eventually remove while tidying up, or that will be absent when a colleague copies the pipeline into a new project.
The check turns that into a red build with an instruction attached.
And a test, because the line is deletable It parses the pipeline YAML and asserts the line is still there.
Slightly unusual to test your own CI config, but this is a config value with a silent failure mode, which is exactly the kind worth pinning.
The general shape Ask of any conditional deployment: what does this do when its input is missing rather than wrong?
Wrong input usually errors.
Missing input often produces an empty result that looks like a legitimate negative.
Empty and "nothing to do" are the same value, and only one of them is safe.
Anywhere those two are indistinguishable, make the code refuse rather than assume.
Full context: [https://www.linkedin.com/pulse/enterprise-microsoft-fabric-cicd-selective-one-azure-devops-ghosh-uxzsf] Code: [https://github.com/VEDAFORGE/fabric-cicd-reference/tree/v2.0.0]