fix(github): Fall back to git blobs API for large files in GetFileContent

[jayceebernardino]

what

• GetFileContent on the GitHub client now falls back to the Git Blobs API when a file exceeds GitHub's 1MB Contents API limit
• Affects the skip-clone-no-changes feature, which uses GetFileContent to fetch atlantis.yaml before deciding whether to clone

why

• GitHub's GET /repos/{owner}/{repo}/contents/{path} API returns an empty content field for files larger than 1MB, causing skip-clone-no-changes to fail with a base64 decode error
• The Git Blobs API (GET /repos/{owner}/{repo}/git/blobs/{sha}) has no size limit and returns the same base64-encoded content — the SHA needed to call it is already present in the Contents API response

tests

• Added TestClient_GetFileContent with three cases: normal file, file not found, and file over 1MB triggering the blobs fallback

references

• GitHub docs: Get repository content — notes the 1MB limit
• GitHub docs: Get a blob — no size restriction

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a fallback in GetFileContent to use the Git Blobs API when the GitHub Contents API omits content for files over 1MB, preventing base64 decode failures and unblocking skip-clone-no-changes.

Changes:

• Add Contents API → Blobs API fallback when the Contents response has empty/missing content.
• Add unit tests covering normal file, not found, and large-file fallback behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.

File	Description
server/events/vcs/github/client.go	Implements Blobs API fallback when Contents API returns empty content for large files.
server/events/vcs/github/client_test.go	Adds tests validating normal, not-found, and large-file fallback behavior.