A one-commit checkout and a trailing || true let 41 PRs skip tests under green CI
GitHub Actions' default one-commit checkout let 41 pull requests skip their tests over three weeks while CI stayed green, a dev.to author reports. The author's change-detection step read git's fatal error as an empty diff, and the run that exposed it showed a test job that finished in 4 seconds.
The Engineer · Build desk
Key figures: in the run that exposed the problem, the test job finished in 4 seconds, printing 'No code changes, skipping tests'. git diff origin/main...HEAD exited 128 on a depth-1 checkout. The PR that broke main after a green CI run changed 14 files in src/.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Test job time in the run that exposed the problem | 4 seconds | 10 | |
| git diff exit code | 128 exit code | 2 | |
| Files changed in src/ | 14 files | 11 |
What happened
- With a depth-1 checkout there is no origin/main ref, so git diff origin/main...HEAD prints a fatal error and exits 128.
- On a pull_request event the one fetched commit is GitHub's merge commit at refs/pull/<N>/merge, which merges the PR head into the current base.
- The step ran as bash -e without pipefail, so grep's status won, and the trailing || true then swallowed both git's fatal error and grep's no-match.
- It surfaced on a Tuesday, when a PR that changed 14 files in src/ broke main after a green CI run.
Why it matters
- exposure Any step that diffs against a base ref, reads tags or counts commits on the default checkout is affected. git rev-list --count returns 1 without an error, so version strings can fall back to a first-release default.
- cost Full history costs clone time on every run, and the post names that as the price of fetch-depth: 0. The depth-2 variant avoids it but is scoped to pull_request events.
- decision Teams with skip logic have to choose what happens when the diff cannot be computed. We think a change-detection step that errors should run the full suite or fail, never skip.
Fetching full history makes origin/main exist, but the step would still treat any git failure as an empty diff [7][8]. That is why the post's fix has two parts: more history first, then a step that stops the job when git errors [16][17].
Setting pipefail by itself would not close it. The `|| true` sits after the pipeline, and bash returns success from `pipeline || true` whether the pipeline passed or failed [19]. Bash did what it was told. The only case that needs a guard is grep's exit 1 on no match [8], so in our view the right shape is `git diff` on its own line under errexit, with `|| true` attached to grep alone.
The 41 PRs over three weeks work out to about 14 a week [18]. Each of them went green [12]. The post's author wrote that git's fatal message sat in the log as "gray text above a green checkmark" [13]. The step also passes on a laptop, because a local clone has origin/main and full history [3]. Running the script by hand will not reproduce the failure.
All of this rests on one author's repository. The 41 count and the three-week window are the author's own numbers, and the post does not say how many of those 41 PRs would have failed their tests. The author bets that many monorepos carry some version of the same step [20]. That is a guess, not a survey.
For the finding to transfer, a workflow needs the default checkout, a diff against a remote ref, and a fallback that treats an error as empty output. A workflow that already sets fetch-depth: 0 does not hit the missing ref [16]. The author's throwaway workflow tests for the first condition. On a repo with years of history it printed true for is-shallow-repository, a log of one commit, one remote ref and zero tags [5].
What to watch
- Whether other teams report the same fail-open pattern in their change-detection steps, since the evidence so far is one repo.
- Whether monorepo affected-only runners fail closed when the base ref is missing; the post says to check for a 'fall back to running nothing' mode.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Insufficient
- Hype gap+6
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
actions/checkout defaults to fetch-depth: 1, which fetches one commit with no parents, no other branches and no tags.
- [2]
With a depth-1 checkout there is no origin/main ref, so git diff origin/main...HEAD prints 'fatal: ambiguous argument' and exits 128.
- [3]
The step works on a laptop because a local clone has origin/main and full history; it only breaks on the runner.
- [4]
On a depth-1 checkout, git diff origin/main...HEAD, git merge-base, git describe, HEAD~1 and git rev-list --count HEAD all fail or return the wrong answer.
- [5]
The author's throwaway workflow, run on a repo with years of history, printed true for is-shallow-repository, a log of 1 commit, a single remote ref for the PR, 0 tags, and both fallback messages.
- [6]
On a pull_request event the single fetched commit is not the branch tip but the merge commit GitHub creates at refs/pull/<N>/merge, merging the PR head into the current base.
- [7]
A run: step with no shell: key runs on Linux as bash -e {0}, which is errexit without pipefail, so a pipeline's exit status comes from its last command, here grep rather than git.
- [8]
The author added || true because grep exits 1 when nothing matches; it swallowed git's fatal error together with grep's no-match, so the CHANGED variable came back empty.
- [9]
An empty CHANGED made the step print 'No code changes, skipping tests' and set skip=true, and the job still passed.
- [10]
In the run that exposed the problem, the test job finished in 4 seconds with one line of output: 'No code changes, skipping tests'.
- [11]
The failure surfaced on a Tuesday, when a PR that changed 14 files in src/ broke main after a green CI run.
- [12]
For three weeks, 41 pull requests skipped the test suite, and every one of them was green.
- [13]
The author wrote that the fatal message was in the log as "gray text above a green checkmark".
- [14]
git rev-list --count HEAD does not error on a depth-1 checkout; it reports one commit, so tools that build a version string from tags or commit counts fall back to a default and can ship artifacts labeled like a first release.
- [15]
Affected-only test runners in monorepo tools hit the same wall when they compare against a base branch, and the author advises checking for a 'fall back to running nothing' mode.
- [16]
fetch-depth: 0 fetches all history, all branches and all tags, so origin/main...HEAD, git describe and changelog generation work as they do locally; its cost is clone time.
- [17]
On pull_request events the author's alternative is fetch-depth: 2 with git diff HEAD^1 HEAD, and in either case git failures should then stop the job.
- [18]
41 skipped PRs over three weeks is about 14 PRs a week.
- [19]
Adding pipefail alone would not stop the step: the exit status of 'pipeline || true' is success whether or not the pipeline fails, so the || true in the post's step still masks git's exit 128.
- [20]
The author said they would bet a lot of monorepos have some version of the same change-detection step.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toGitHub Actions fetch-depth: 1 Made My CI Skip Tests for 41 PRs
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- GitHub ActionsFollow
- Continuous integrationFollow
- Git shallow clonesFollow