Add Link headers for commits

When you use the API to get the commits for a repo (/api/v3/projects/:id/repository/commits), the result is paginated but there is Link header added to the response headers.

Is this done explicitly to avoid some performance issues or can this still be implemented?

Link headers are working fine for me. Is this still an issue or can we close this?

Sorry but I did not get the exact issue or question.

I just checked and it is still an issue.

Let me clarify it,

When you request a resource via the API, say a project's issues, in the response headers you'll find something like this:

Link: <https://gitlab.com/api/v3/projects/13083/issues?page=2&per_page=0>; rel="next", <https://gitlab.com/api/v3/projects/13083/issues?page=1&per_page=0>; rel="first", <https://gitlab.com/api/v3/projects/13083/issues?page=226&per_page=0>; rel="last"

However, when requesting a project's commits, the Link response header is missing but the result is paginated.

Just checked this on my GitLab server v8.3.2 and can confirm this is still an issue. Link response header is missing when listing commits through API.

Example: https://gitlab.com/api/v3/projects/13083/repository/commits?per_page=1

Added ~131895 label

Added ~123454 label

I'd be happy to take a stab at this issue as my first contribution! Is there anywhere I could add a regression test for this behavior?

It appears the source of the issue is an incompatibility between the way the array of commits is generated at the /projects/:id/repository/commits endpoint and the way plain arrays are usually paginated with Kaminari.paginate_array. The code for this particular route lives here.

Let's take a look at the last line of the method that presents the response.

present commits, with: Entities::RepoCommit

We could try to use the common paginate helper.

present paginate(commits), with: Entities::RepoCommit

That fails, however, because commits is a flat array. Kaminari extends ActiveRecord::Relation and ActiveRecord::Model with #page, and the paginate helper expects its argument to respond to that method. Luckily, there is a convenience method: Kaminari.paginate_array to wrap an array into a pageable object. Something like this may suffice:

present paginate(Kaminari.paginate_array(commits)), with: Entities::RepoCommit

And here we run into the crux of the issue. With the above changes you do get a Link header, but the parameters are incorrect. For instance, a request like

GET /api/v3/projects/8/repository/commits?page=1&per_page=20

receives this response (only relevant headers shown):

HTTP/1.1 200 OK
Link: <http://localhost:3000/api/v3/projects/8/repository/commits?id=8&page=1&per_page=20>; rel="first", <http://localhost:3000/api/v3/projects/8/repository/commits?id=8&page=1&per_page=20>; rel="last"
Status: 200 OK
X-Next-Page:
X-Page: 1
X-Per-Page: 20
X-Prev-Page:
X-Total: 20
X-Total-Pages: 1

Most notably, X-Total says there are only 20 commits in this repository. Clearly that is not true. I can perform the same request with a per_page parameter set to 100 and I'll get more commits. This is because our working solution reuses the same pagination parameters to construct the commit range array as it uses to paginate the array. That way, the array's size is the same as per_page, and there's always only one page. You will, for example, receive an empty body if you try to access the second page:

GET /api/v3/projects/8/repository/commits?page=&per_page=20

HTTP/1.1 200 OK
Link: <http://localhost:3000/api/v3/projects/8/repository/commits?id=8&page=1&per_page=20>; rel="prev", <http://localhost:3000/api/v3/projects/8/repository/commits?id=8&page=1&per_page=20>; rel="first", <http://localhost:3000/api/v3/projects/8/repository/commits?id=8&page=1&per_page=20>; rel="last"
Status: 200 OK
X-Next-Page:
X-Page: 2
X-Per-Page: 20
X-Prev-Page: 1
X-Request-Id: d79ef842-8ac6-4173-a250-7e97a35d588b
X-Runtime: 0.100244
X-Total: 20
X-Total-Pages: 1

---

To solve this, we need to know the total number of commits behind a given ref. Thankfully, there's already Repository#commit_count to help with that.

mentioned in merge request !5298 (closed)

I've had !5298 (closed) open for about two months now. Is there anything else I need to do, or should I perhaps close the MR?

The GitLab commits API does not conform to the other APIs.

Commits start pagination at page 0 instead of page 1.

In addition, as this issue implies, no Link headers are sent back in violation of GitLab API documentation.

I hope the MR is able to get in (in some format).

Mentioned in merge request !5298 (closed)

I have a user who was looking for this link header for commits, tags, and branches in a repo. (@dblessing)

removed ~131895 label

mentioned in issue #13605 (closed)

added breaking change label

changed milestone to %9.0

mentioned in commit cf52c5db

mentioned in merge request !9679 (merged)

mentioned in issue #20070 (closed)

@oswaldo I am assigning it to you, since you are working on this in !9679 (merged).

assigned to @oswaldo

removed ~123454 label

mentioned in commit 84c4ca89

mentioned in commit d74060fc

mentioned in commit e34da168

mentioned in commit 135cab4c

mentioned in commit 647ff597

mentioned in commit c78eebc7

mentioned in commit 5d006fc6

mentioned in commit 473cab81

closed via merge request !9679 (merged)

mentioned in merge request !14785