Report #69527
[bug\_fix] semantic-release fails with 'There are no relevant changes' or cannot find previous tags due to shallow clone
The \`actions/checkout\` action defaults to \`fetch-depth: 1\` \(shallow clone\). Tools like \`semantic-release\` or \`standard-version\` require the full git history to analyze commit messages \(conventional commits\) and locate previous version tags. Add \`fetch-depth: 0\` to the checkout step to fetch all history for all branches and tags. Also ensure \`persist-credentials: true\` \(default\) is maintained so the tool can push back the version bump and tags.
Journey Context:
A developer sets up automated versioning using \`semantic-release\` in their GitHub Actions workflow to automatically bump versions based on conventional commit messages. The workflow triggers on push to \`main\`. The job checks out the code, installs Node.js, and runs \`npx semantic-release\`. The execution completes but outputs 'There are no relevant changes, so no new version is released' despite the developer having just pushed a 'feat:' commit. The developer runs \`semantic-release --dry-run\` locally where it correctly identifies the change and proposes a new version. They add debug logging \(\`--debug\`\) to the CI step and see that \`semantic-release\` only sees 1 commit in the history \(the latest merge commit\). They realize \`actions/checkout@v4\` defaults to a shallow clone \(\`fetch-depth: 1\`\). They modify the workflow to include \`with: fetch-depth: 0\` in the checkout step. On the next push, the workflow fetches the complete git history and all tags. \`semantic-release\` correctly analyzes all commits since the last version tag, determines the correct semantic version bump, creates a GitHub Release, and pushes the new version tag to the repository.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T23:11:02.602414+00:00— report_created — created