| /** |
| * Some “list” response that can be paginated have a different response structure |
| * |
| * They have a `total_count` key in the response (search also has `incomplete_results`, |
| * /installation/repositories also has `repository_selection`), as well as a key with |
| * the list of the items which name varies from endpoint to endpoint: |
| * |
| * - https://developer.github.com/v3/search/#example (key `items`) |
| * - https://developer.github.com/v3/checks/runs/#response-3 (key: `check_runs`) |
| * - https://developer.github.com/v3/checks/suites/#response-1 (key: `check_suites`) |
| * - https://developer.github.com/v3/apps/installations/#list-repositories (key: `repositories`) |
| * - https://developer.github.com/v3/apps/installations/#list-installations-for-a-user (key `installations`) |
| * |
| * Octokit normalizes these responses so that paginated results are always returned following |
| * the same structure. One challenge is that if the list response has only one page, no Link |
| * header is provided, so this header alone is not sufficient to check wether a response is |
| * paginated or not. For the exceptions with the namespace, a fallback check for the route |
| * paths has to be added in order to normalize the response. We cannot check for the total_count |
| * property because it also exists in the response of Get the combined status for a specific ref. |
| */ |
| import { Octokit } from "@octokit/core"; |
| import { OctokitResponse } from "./types"; |
| export declare function normalizePaginatedListResponse(octokit: Octokit, url: string, response: OctokitResponse<any>): void; |
