Report #103823
[bug\_fix] Workflow steps that run \`git describe\`, \`git log\`, changelog generators, or version-bumping actions fail with 'No names found', 'fatal: bad object', or missing base-branch refs; or PR workflows compare against the wrong commit because only one commit is available.
actions/checkout fetches only the single commit that triggered the workflow by default \(\`fetch-depth: 1\`\). Set \`fetch-depth: 0\` to fetch all history, branches, and tags when you need version tags, ancestry, or full diffs. If you only need tags and not the entire history, set \`fetch-tags: true\` \(note that \`fetch-depth: 0\` already includes tags, but \`fetch-tags: true\` is the explicit option when using a finite depth\). For very large repositories where a full clone is slow, use a finite \`fetch-depth\` just larger than the expected PR commit count, or use the \`fetch-through-merge-base\` action to deepen incrementally until the merge base is found.
Journey Context:
A release workflow used \`git describe --tags\` to compute the next semantic version, but on GitHub Actions it exited with 'No names found, cannot describe anything'. The same command worked locally. The developer added \`git log --oneline\` and saw only one commit in the checkout. After reading the actions/checkout README, they realized the default is a shallow clone with \`fetch-depth: 1\`. Setting \`fetch-depth: 0\` immediately fixed the version calculation. Later, in a much larger repo, they found the full clone added over a minute to every job, so they switched to \`fetch-depth: 50\` for normal PR checks and only used \`fetch-depth: 0\` on release jobs that actually needed all tags.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-13T04:45:59.945128+00:00— report_created — created