feat: Support push and merge_group events with use_rest_api

[npwolf]

Closes #2835

Summary

• Extends use_rest_api mode to support push and merge_group events, not just pull_request*
• For push events, uses repos.compareCommits with payload.before/payload.after
• For merge_group events, uses repos.compareCommits with payload.merge_group.base_sha/head_sha
• Existing pull_request* behavior is unchanged (still uses pulls.listFiles)
• No changes to the git-based code path or any existing inputs/outputs

Motivation

Currently, use_rest_api: true works on pull_request events but fails when the same workflow triggers on merge_group (merge queue) or push (landing on target branch). This forces users of large repos to either add actions/checkout (losing the performance benefit) or maintain separate workflow configurations per event type.

The repos.compareCommits endpoint returns files in the same shape as pulls.listFiles, so all downstream processing (filtering, dir_names, output formatting, etc.) works without changes.

Prior art

This pattern is proven in two maintained forks of jitterbit/get-changed-files:

• Ana06/get-changed-files (71 stars) — supports pull_request, pull_request_target, and push via API
• npwolf/get-changed-files — supports pull_request, pull_request_target, push, and merge_group via API

Changes

File	Change
src/changedFiles.ts	Branch endpoint selection in getChangedFilesFromGithubAPI by event type
src/main.ts	Allow push/merge_group through to the REST API path
src/__tests__/changedFiles.test.ts	New: 9 unit tests for API function (existing + new event types)
src/__tests__/main.test.ts	New: 4 unit tests for routing logic
dist/, lib/	Rebuilt

Test plan

• All 13 new unit tests pass
• All pre-existing tests unaffected
• TypeScript compiles cleanly
• Lint passes with zero warnings
• E2E: test with a real push event workflow using use_rest_api: true

Limitations

The same 3,000-file cap that applies to pulls.listFiles also applies to repos.compareCommits. This is a GitHub API limitation.

[codacy-production]

Not up to standards ⛔

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 36 complexity · 7 duplication

Metric	Results
Complexity	36
Duplication	7

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[npwolf]

Hey @jackton1 — I pushed a small fix to the CI build job to get the eslint check passing for this fork PR.

The issue: The build job's checkout step specifies repository (to check out the fork) but no ref, so it defaults to the fork's main branch instead of the PR head. ESLint then fails because it can't find files that only exist on the feature branch (src/__tests__/changedFiles.test.ts).

The fix: Added ref: ${{ github.head_ref }} to the checkout step, along with a comment explaining why. This is safe since head_ref is only used as a with: input to actions/checkout (not interpolated into a shell script), and the fork's code is already being checked out and executed via the existing repository parameter.

Let me know if you'd prefer a different approach or if there are repo conventions I should follow here — happy to adjust.

[jackton1]

Thanks, @npwolf. For this change, I'd need to do some more validation on my end, but nice work.

[jackton1]

Hey @jackton1 — I pushed a small fix to the CI build job to get the eslint check passing for this fork PR.

The issue: The build job's checkout step specifies repository (to check out the fork) but no ref, so it defaults to the fork's main branch instead of the PR head. ESLint then fails because it can't find files that only exist on the feature branch (src/__tests__/changedFiles.test.ts).

The fix: Added ref: ${{ github.head_ref }} to the checkout step, along with a comment explaining why. This is safe since head_ref is only used as a with: input to actions/checkout (not interpolated into a shell script), and the fork's code is already being checked out and executed via the existing repository parameter.

Let me know if you'd prefer a different approach or if there are repo conventions I should follow here — happy to adjust.

This is fine

[jackton1]

@all-contributors please add @npwolf for code and test

[allcontributors]

@jackton1

I've put up a pull request to add @npwolf! 🎉

[npwolf]

Thanks @jackton1 !