Migrate to GitHub REST API 2026-03-10

[jamietanna]

Describe the proposed change(s).

Once we're in a place to start migrating to the new GitHub APIs, we should do so.

Note

We will only be able to stop supporting the 2022-x APIs once all supported GitHub Enterprise Server versions support it.

[jamietanna]

It appears we may not have much to change for the breaking changes (⚠️ citation + human validation needed!)

╭─── Claude Code v2.1.62 ──────────────────────────────────────────────────────╮
│                                       │ Tips for getting started             │
│             Welcome back!             │ Run /init to create a CLAUDE.md fil… │
│                                       │ ──────────────────────────────────── │
│                ▐▛███▜▌                │ Recent activity                      │
│               ▝▜█████▛▘               │ No recent activity                   │
│                 ▘▘ ▝▝                 │                                      │
│                                       │                                      │
│    Sonnet 4.6 · API Usage Billing     │                                      │
│   ~/workspaces/renovatebot/renovate   │                                      │
╰──────────────────────────────────────────────────────────────────────────────╯

  /model to try Opus 4.6

❯ Given the breaking changes noted in https://docs.github.com/en/rest/about 
  -the-rest-api/breaking-changes?apiVersion=2026-03-10 can you see if we're 
   affected?                                                                

⏺ Fetch(https://docs.github.com/en/rest/about-the-rest-api/breaking-changes?apiV
       ersion=2026-03-10)
  ⎿  Received 29.4KB (200 OK)

⏺ Now let me search the codebase for usages of these deprecated fields and
  behaviors.

⏺ Searched for 15 patterns, read 2 files (ctrl+o to expand)

⏺ Let me look at the schema spec for submodule handling, and also check what the
   schema looks like for the earlier part of the file.

⏺ Searched for 3 patterns, read 3 files (ctrl+o to expand)

⏺ Let me check one more thing - installation deletion handling:

⏺ Searched for 1 pattern (ctrl+o to expand)

⏺ Based on my analysis, here's what I found:

  Summary

  One affected area: singular assignee field removal

  - lib/modules/platform/github/types.ts:62: assignee?: { login?: string } in
  GhRestPr type
  - lib/modules/platform/github/common.ts:38: !!pr.assignee || 
  isNonEmptyArray(pr.assignees)

  The API will stop returning the singular assignee field, only assignees array.
   The runtime behavior won't break since the code falls back to assignees, but
  the dead !!pr.assignee check and the type field should be cleaned up.

  Not affected:
  - merge_commit_sha — not used
  - use_squash_pr_title_as_default / has_downloads / hub_url /
  authorizations_url — not used
  - Rate limit rate property — not used (rate-limiting done via HTTP headers)
  - Repository content submodule type change ("file" → "submodule") — already
  handled; GithubOtherContent already includes z.literal('submodule')
  (schema.ts:94)
  - Code scanning enum changes, SARIF Content-Type, workflow dispatch status
  code — none of these endpoints are used
  - Installation deletion status code — not used
  - selected_repository_ids for Dependabot — not used

  Want me to make the fix — remove assignee from GhRestPr and simplify the check
   in common.ts to only use assignees?

✻ Cogitated for 1m 46s