Launchpad: API search for PRs on GitLab

[sergeibbb]

This issue is a follow-up of #3543

---

Todo

• ✅ Search for PRs on GitLab
• ✅ Perform the PR search for all connected providers
• ✅ Group found repo+prID pairs by provider to perform the more precise search
• ✅ Search GitLab PR by PR URL
• ✅ Get head-ref id on each PR, to be able to show checkout-like actions

Follow-ups

• ⏺️ Search by number on current repositories

Testing notes

Connect both GitLab and GitHub. Search by:

• GitHub URL of a local PR (a PR from your repositories)
• GitLab URL of a local PR
• GitHub URL in internet (a random PR on internet)
• GitLab URL in internet
• text query

Pay attention to user avatars. GitLab's graph-ql returns them differently in different requests: sometimes it's an URL, but sometimes it's just a path.

Make sure that owner/repo is shown.

Disconnect GitHub. Search by a text query.

[sergeibbb]

Hi @axosoft-ramint , @eamodio

I have a following question. It looks like GitLab's GraphQL is not able to search for PRs in general. It can does the following:

• get for a user: one of the following
  • assignedMergeRequests
  • authoredMergeRequests
  • reviewRequestedMergeRequests
• get for a project/group

Now for the Launchpad "get for a user" set of requests is used but retrieving only open ones: state:opened

Also there is a REST API endpoint that just searches everywhere, e.g.: https://gitlab.com/api/v4/search?scope=merge_requests&search=flight

What I can do:

1. use "get by user" requests withtout state:opened limitations. By doing that I loose PRs that are not associated with the current user.
2. use "get by project" request for currently opened repositories. By doing that I loose PRs that belong to other projects.
3. use REST API endpoint. The results can be too wide, but now we have same for GitHub.

For now I'm going to continue with # 3 until we choose another option or find a better solution.

Also, maybe I just wrong about GraphQL possibilities and it can search, and I just haven't found how to do that.

What do you think?

[axosoft-ramint]

I feel like since what we're doing with GitHub on a search is "search everywhere", we should have equivalent behavior for GitLab. So 3 sounds right.