Grapify the merge request API

Grapfiy the merge request API. I removed the test for checking if the source branch can be changed since this is an unused parameter. IMHO the test does not make sense.

What are the relevant issue numbers?

Related to #22928 (moved)

Mentioned in issue #22928 (moved)

Added 1 commit:

• 87a44a97 - Grapify the merge request API

Compare with previous version

Reassigned to @razer6

Added 1 commit:

• 748fe08e - Grapify the merge request API

Compare with previous version

Added 1 commit:

• 13b91104 - Grapify the merge request API

Compare with previous version

Resolved all discussions

Added 322 commits:

• 13b91104...36fa5d66 - 321 commits from branch master
• 9dbb0417 - Grapify the merge request API

Compare with previous version

Reassigned to @rymai

Status changed to merged

Mentioned in commit 68978697

@rymai @razer6: This MR introduced a change that in my opinion should be treat as a regression. I have a live example of it - https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/scripts/prepare-changelog-entries.rb#L36.

Until this change was merged I was able to request the API with http://gitlab.com/api/v3/projects/gitlab-org%2Fgitlab-ci-multi-runner/merge_requests?iid[]=380&iid[]=381&iid[]=382&...&per_page=15&private_token=MY_PRIVATE_TOKEN GET request. Thanks to this I had information about multiple merge requests with one request which was faster and less heavy for GitLab than 15 independent requests for each merge request.

Now iid can be used only as a scalar value, not as an array, so http://gitlab.com/api/v3/projects/gitlab-org%2Fgitlab-ci-multi-runner/merge_requests?iid=380&per_page=15&private_token=MY_PRIVATE_TOKEN will work, but the request I've wrote above will end with:

HTTP/1.1 400 Bad Request
(... more headers ...)

{
    "error": "iid is invalid"
}

I think this should be treat as a regression because it changes the way how API works and all scripts which were relaying on parameters that can be passed as arrays now need to be rewritten.

Also, in current implementation there is no sense to have iid parameter for this endpoint at all. If I can use only one iid value for filtering, then the request will return only one merge request because the iid is unique for each MR in context of one project. And if I can receive information about only one MR then I could use the /api/v3/projects/:id/merge_requests/:merge_request_id endpoint instead of /api/v3/projects/:id/merge_requests/ with filtering.

---

I've checked Grape documentation and changing :

  optional :iid, type: Integer, desc: 'The IID of the merge requests'

to

  optional :iid, type: Array[Integer], desc: 'The IID of the merge requests'

at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7358/diffs#66870a4a33e80e54b54136ee83ff2b54b2f5b2ed_42_44, should get the previous behavior of API back. I've done a quick test and it worked for me.

I don't know if this was discussed and this is intended change. If no, then we should open a regression issue and check all changed API definitions from #22928 (moved).

Mentioned in merge request !7648 (merged)

@tmaczukin Thanks for the report. I agree this is a change in behavior, but by looking at the documentation, I would expect iid to be a single integer:

• iid (optional) - Return the request having the given iid

And yes this usage "kind of makes sense" since GET /api/v3/projects/:id/merge_requests/:merge_request_id expect :merge_request_id to be an actual ID, not an IID!!!

I think you are using an undocumented / unsupported feature then. That being said, it's a valid use-case so the endpoint should support both iid=42 and iid[]=380&iid[]=381.

Mentioned in commit 7902395f

Mentioned in commit d97ac2f6

mentioned in merge request !8457 (merged)

mentioned in merge request !8793 (merged)

mentioned in issue gitlab#6486