RFR: 1408: GitLabMergeRequest#reviews sometimes finds the wrong commit HASH

[Guoxiong Li]

On Mon, 25 Apr 2022 09:37:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Please consider the following steps:
> 
> - the author creates "commit 1" locally (with hash "95f2d613cf392275075d7c87285845531f5fe827" [1])
> - the author pushes it and creates a merge request in the Gitlab, then the Gitlab creates "version 1" [2] (its hash is the hash of "commit 1") which has the changed files of "commit 1"
> - the author creates "commit 2" locally (with hash "99ca51edfa0063113a2236fce548ba453aee7275" [3])
> - a reviewer approves the MR with the "**version 1**" in the Gitlab. Note: the "commit 2" is not pushed now.
> - the author creates "commit 3" locally (with hash "50b119c4c325053b8151ea6e761a60d1acfbb746" [4]) Note: this step seems optional
> - the author pushes the commits and the gitlab create "version 2" [5] (its hash is the hash of "commit 3") which has the changed files of "commit 1-3"
> 
> When we use the method `GitLabMergeRequest#reviews` to get the reviews list, we can see the review hash is the hash of the "commit 2" ("99ca51edfa0063113a2236fce548ba453aee7275"). But actually, the reviewer only approved "version 1" with hash of the "commit 1" ("95f2d613cf392275075d7c87285845531f5fe827").
> 
> This patch uses the `versions` list instead of all the `commits` list to fix the issue. And when I wrote a test case to verify it, I got a NPE and filed SKARA-1409 to record it. This patch also solves SKARA-1409 so that the reviewer can run the test locally.
> 
> You can use the following config to run the test:
> 
> gitlab.user=<your username in https://gitlab.com>
> gitlab.pat=<your token in https://gitlab.com>
> 
> gitlab.uri=https://gitlab.com
> gitlab.repository=35596381
> gitlab.merge.request.id=2
> gitlab.review.hash=95f2d613cf392275075d7c87285845531f5fe827
> 
> 
> Note: this PR seems have git conflict with [SKARA-1407-PATCH](https://github.com/openjdk/skara/pull/1304). I will solve the conflict when one of them is integrated.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=95f2d613cf392275075d7c87285845531f5fe827
> [2] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379883693
> [3] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=99ca51edfa0063113a2236fce548ba453aee7275
> [4] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?commit_id=50b119c4c325053b8151ea6e761a60d1acfbb746
> [5] https://gitlab.com/lgxbslgx/test/-/merge_requests/2/diffs?diff_id=379907777
> 
> ---

>From the description in issue SKARA-1400 [1]:

> This can happen if multiple commits have the same "created_at" date (the date the commit was pushed to gitlab).

It seems that the `created_at` date is not the date the commit was pushed to gitlab.
Please see the 3 commits of the PR body [2], the "commit 2" and "commit 3" were pushed at the same time but they have different `create_at` date which are their commit date instead of push date.

So I think SKARA-1400 may be a wrong analysis and different commit should have different `create_at` date (which means we don't need to handle the situation of the same `create_at` date).

What's your opinion? Did I miss anything? If you agree with me, I would like to revert SKARA-1400 in this patch.

[1] https://bugs.openjdk.java.net/browse/SKARA-1400
[2] https://gitlab.com/api/v4/projects/35596381/merge_requests/2/commits

-------------

PR: https://git.openjdk.java.net/skara/pull/1306