bujjibabukatta opened a new pull request, #8942:
URL: https://github.com/apache/devlake/pull/8942

   ## Summary
   
   Fixes the "wrong deployment reference" bug where PRs were incorrectly
   associated with old deployments, causing massively skewed median lead
   time for change metrics.
   
   ### Root cause
   
   `batchFetchDeployments` used **only** diff-based mapping, which
   deliberately excludes the very first deployment in a collected window
   (via `prev_success_deployment_commit_id <> ''`). This guard is correct
   for the diff path — without it, the first deployment would absorb every
   historical PR via `commits_diffs`. However, it also blocked a legitimate
   case: when a deployment's own `commit_sha` **directly equals** a PR's
   `merge_commit_sha`, that association is precise and safe, even for the
   first deployment.
   
   This caused the scenario reported in #8790: projects using the GitLab
   connector to onboard historical deployments for the first time would see
   the first deployment incorrectly pull in all old MRs.
   
   ### Fix
   
   Two-phase strategy in `batchFetchDeployments`:
   
   **Phase 1 — direct match (new):**
   Query all successful PRODUCTION deployments in the project, keyed by
   `commit_sha`. If a deployment's `commit_sha` equals the PR's
   `merge_commit_sha`, associate them. No `commits_diffs` join needed —
   the match is exact, so there is no over-mapping risk.
   
   **Phase 2 — diff-based fallback (unchanged):**
   Retain the existing `commits_diffs` join with the
   `prev_success_deployment_commit_id <> ''` guard. Only fills in PRs not
   already resolved by Phase 1.
   
   ### Test coverage
   
   All existing e2e test cases in `calculate_change_lead_time_test.go`
   pass without change. In the existing fixtures, PR `merge_commit_sha`
   values are distinct from deployment `commit_sha` values, so Phase 1
   produces no matches and Phase 2 runs identically to before — verifying
   no regression.
   
   The bug scenario (Phase 1 actually matching) is the real-world case
   described in #8790 and #8188 and is not yet covered by a fixture test.
   A follow-up test case with `deployment.commit_sha == pr.merge_commit_sha`
   would be a good addition.
   
   ### Related issues
   Closes #8790
   Related: #8188, #8249, #7193


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to