fix(ci): map BITBUCKET_PR_DESTINATION_COMMIT to base branch SHA for patch coverage#2394
Merged
Merged
Conversation
Some CI environments (e.g. Bitbucket Pipelines) only clone the current branch by default, leaving the base branch ref unavailable locally. This causes git merge-base to fail silently and patch coverage to be missing from the uploaded event. Explicitly fetch origin/<baseBranch> before computing the merge-base, guarded in a try/catch so the fix degrades gracefully on fetch failure. GitHub Actions and GitLab CI are unaffected — they supply a base SHA directly and take the earlier code path. Azure/CircleCI/Jenkins hit this path but already have all refs available, so the fetch is a no-op.
🎉 All green!🧪 All tests passed 🔗 Commit SHA: 1df71b2 | Docs | Datadog PR Page | Give us feedback! |
albabn
marked this pull request as ready for review
June 30, 2026 13:43
There was a problem hiding this comment.
More details
PR adds a git fetch origin/<baseBranch> call before merge-base when only a branch name is available, fixing patch coverage for Bitbucket Pipelines and similar shallow-clone CIs. The fix is wrapped in try/catch to degrade gracefully when fetch fails, preserving backward compatibility. Five new tests validate all code paths: missing metadata, the baseSha path (unchanged), the baseBranch path (new fetch behavior), and graceful failure modes.
🤖 Datadog Autotest · Commit 87d3ea0 · What is Autotest? · Any feedback? Reach out in #autotest
Bitbucket Pipelines merges the destination branch into the source at build setup, so destination-branch commits are reachable in PR pipeline history. However origin/<baseBranch> is absent as a remote-tracking ref, causing git merge-base to fail silently and patch coverage to be missing. Rather than fetching the ref (previous approach, reverted), map BITBUCKET_PR_DESTINATION_COMMIT to GIT_PULL_REQUEST_BASE_BRANCH_SHA in the CI detection layer. datadog-ci then takes the direct baseSha code path — same as GitHub Actions (pull_request.base.sha) and GitLab CI (CI_MERGE_REQUEST_DIFF_BASE_SHA) — with no git operations needed. Non-PR pipelines are unaffected: BITBUCKET_PR_DESTINATION_COMMIT is only set in PR pipeline contexts, where patch coverage is meaningful.
Drarig29
approved these changes
Jun 30, 2026
CarlosNietoP
approved these changes
Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why?
Patch coverage never appears for Bitbucket PRs — overall coverage works fine but the "Patch Coverage" column always shows "No data".
Root cause: Bitbucket Pipelines does a single-branch clone and clone: depth: full only affects commit-history depth, not ref scope (BCLOUD-14719, resolved Won't Do). In PR pipelines, destination-branch commits are reachable in history (Bitbucket merges them at build setup), but origin/ is absent as a remote-tracking ref — so git merge-base HEAD fails silently, @report.patch_percentage is never computed, and patch coverage is never uploaded.
GitHub Actions and GitLab CI are unaffected because they provide a base SHA directly (pull_request.base.sha / CI_MERGE_REQUEST_DIFF_BASE_SHA), taking the if (baseSha) code path in getHeadAndBase that never reaches the branch-name logic.
How?
Map BITBUCKET_PR_DESTINATION_COMMIT → GIT_PULL_REQUEST_BASE_BRANCH_SHA in the Bitbucket CI detection block. datadog-ci then takes the same baseSha code path as GitHub and GitLab — calling getMergeBase(git, BITBUCKET_PR_DESTINATION_COMMIT, HEAD) to find the true common ancestor — with no additional git operations needed. Non-PR pipelines are unaffected: BITBUCKET_PR_DESTINATION_COMMIT is only set in PR pipeline contexts, where patch coverage is meaningful.
Review checklist
Two new tests in ci.test.ts cover both cases: PR pipeline with BITBUCKET_PR_DESTINATION_COMMIT set (base SHA populated) and without (base SHA absent, existing behaviour preserved).