aboutsummaryrefslogtreecommitdiffstats
path: root/tests/integration
diff options
context:
space:
mode:
authorSebastian Brückner <mail@invlid.com>2023-10-29 13:29:33 +0000
committerGitHub <noreply@github.com>2023-10-29 21:29:33 +0800
commit02dae3f84b80047bef391960eea1350d551e4d72 (patch)
tree844b4f10602b9f2af2927c9ea7ce240d40942185 /tests/integration
parent641e8165c7ebcebe7a323d515e1409ca9926a6c2 (diff)
downloadgitea-02dae3f84b80047bef391960eea1350d551e4d72.tar.gz
gitea-02dae3f84b80047bef391960eea1350d551e4d72.zip
Fix merge base commit for fast-forwarded GitLab PRs (#27825)
Due to a bug in the GitLab API, the diff_refs field is populated in the response when fetching an individual merge request, but not when fetching a list of them. That field is used to populate the merge base commit SHA. While there is detection for the merge base even when not populated by the downloader, that detection is not flawless. Specifically, when a GitLab merge request has a single commit, and gets merged with the squash strategy, the base branch will be fast-forwarded instead of a separate squash or merge commit being created. The merge base detection attempts to find the last commit on the base branch that is also on the PR branch, but in the fast-forward case that is the PR's only commit. Assuming the head commit is also the merge base results in the import of a PR with 0 commits and no diff. This PR uses the individual merge request endpoint to fetch merge request data with the diff_refs field. With its data, the base merge commit can be properly set, which—by not relying on the detection mentioned above—correctly imports PRs that were "merged" by fast-forwarding the base branch. ref: https://gitlab.com/gitlab-org/gitlab/-/issues/29620
Diffstat (limited to 'tests/integration')
0 files changed, 0 insertions, 0 deletions