BUG: Gitlab Commits Before Date Needs More Logic

[jimrobison]

Describe the bug
Using the first commit returned has proven to not be the best source for the retrieval of merge requests details.

Expected behavior
The before field is intended to help limit the number of merge request details based on the last commit date for the default branch. By using the first record, this may not always include all of the related merge requests, throwing the scoring calculation off.

Additional context
I believe it would be better to calculate the date by cycling through the commits to determine the best date to use. I have a this is a working branch that I'm working through while validating the Code-Review check's scores

[raghavkaul]

By default, GitLab GraphQL returns the most recent merges on a GitLab repo. But we don't guarantee the merge request that brought in a commit on a GitLab repo's main branch is captured by our check - we may undercount - or miss - merge requests in zip if GraphQL and the REST API don't line up. (We use 1 GraphQL query + 1 REST API call instead of 1 REST API call per commit to find the linked Merge Request, which wouldn't scale).

The purpose of using mergedBefore in getMergeRequestDetail is to improve this - "don't give me any merge requests newer than the newest commit I've listed". But, I think you're right that before := commitsRaw[0].CommittedDate may not reflect the commit date of the newest commit (it might be much older, therefore leading to a lower score). We might fix this is to find a better bound commit date in commitsRaw, or by making a single API query to ListMergeRequestsByCommit to get the right date for before.

[LappleApple]

Bug affects scoring at the margins