googleapis / googleapis/release-please
Current hardcoded limits can timeout Github API unexpectedly
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 588
- Avg merge
- 12h 16m
- Merged PRs (30d)
- 7
Description
#### Environment details
- OS: ubuntu-latest
- Node.js version: v18
- npm version: N/A
- `release-please` version: 16.10.0
#### Steps to reproduce
1. Run release-please against our current repository/branch configuration. No options are specified in the manifest presently except for specifying a simple release strategy and 4 extraFiles to update.
2. Receive an error response (below)
#### Notes
I can reproduce the error directly by manually querying the API call found here (above): https://github.com/googleapis/release-please/blob/08331fa555ed482f675fb3e9dd5b0a5296e200a3/src/github.ts#L442-L449 with what `release-please` is calling. We have had a few very large commits/merges recently and it is causing the Github API to throw an error which is preventing release-please from completing. We get the following currently:
```
Running release-please version: 16.10.0
❯ Fetching release-please-config.json from branch REDACTED
❯ Fetching .release-please-manifest.json from branch REDACTED
✔ Building releases
✔ Building strategies by path
❯ .: simple
❯ Fetching release-please-config.json from branch REDACTED
❯ Fetching .release-please-manifest.json from branch REDACTED
✔ Building pull requests
✔ Building strategies by path
❯ .: simple
✔ Collecting release commit SHAs
❯ release search depth: 400
❯ Fetching releases with cursor undefined
❯ Found release for path ., v3.0.0
❯ release for path: ., version: 3.0.0, sha: REDACTED[22](REDACTED)REDACTED
✔ Collecting commits since all latest releases
❯ commit search depth: 1
❯ Set(1) { 'REDACTED[23](REDACTED)REDACTED' }
❯ Fetching merge commits on branch REDACTED with cursor: undefined
Error: release-please failed: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.
```
If I tweak the parameters however, I can get the query to succeed. Either setting a lower `num` value (15 works, 20 doesn't for example), **or** a lower `maxFilesChanged` (50 works, 75 doesn't), will make the query succeed.
Can these values become configurable? Alternatively, is there something we can do to short-circuit this? Setting `bootstrap-sha` on the most recent, uncomplicated, commit does nothing to remedy.
Contributor guide
Assessment
This issue has not been assessed yet.