You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
According to the pagination documentation, the `next` property of a paginated collection is the recommended way to 'loop' through your collections.
The last page of a collection should omit the value of `next` to indicate this is the last page, as described in the documentation.
Lack of a next link in the response indicates the end of the collection.
On the last page of a collection, the `next` value actually links back to the first page:
The workaround is to of course generate your own URL, but the whole purpose is to not have to do this:
However, clients are not expected to construct URLs themselves by manipulating the page number query parameter. Instead, the response contains a link to the next page. This link should be treated as an opaque location that is not to be constructed by clients or even assumed to be predictable.
This looks like a bug with the repository variables endpoint. There are actually two bugs:
The first one is that the links for "previous" and "next" are invalid, as you can see in the sample response you posted here. This bug is tracked in the following bug report: https://jira.atlassian.com/browse/BCLOUD-20910
The "next" field is indeed present even when there is no next page. I created a bug report for this here: https://jira.atlassian.com/browse/BCLOUD-22441
If you have less than 100 repository variables, you can use ?pagelen=100 in the API call (100 is the maximum allowed value for pagelen for this endpoint). All variables will then be returned in one page, and the "next" field will not be included in the response.
Thanks for dissecting the scenario in smaller issues, and link/creating the appropriate tickets :)
The use-case is needed for an infinite amount of results (used for a Terraform Provider), as such I will likely construct my own pagination URL increasing the page parameter in every iteration.