-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Description
SHA: 0f9cbae
PR: #36252
I spent a few hours investigating, but never completely understood. Two questions:
-
For this specific run, why did we need to call the search API for this commit SHA? If the triggering event was workflow_run:pull_request_target, why isnt' the SHA associated with a PR now?
- Answer: Because the PR was closed immediately before the WF ran.
-
Why are we calling the search API often enough to hit the rate limit? It should only be called in rare cases where the main API failed.
- Answer: Rate limit is 30 calls per minute. With the number of checks and status updates we run, we could hit this on a single closed PR.
Possible Solutions
Use the GH actions cache to avoid repeated calls to search API:
let pr = getCache(sha);
if (pr) {
const commits = getCommits(pr); // higher rate limit than search
if (commits.includes(pr)) {
return pr;
}
}
// cache was empty or stale (cached PR no longer contains commit)
pr = callSearchApi(sha);
if (pr) {
setCache(sha, pr);
}
return pr; // may be NaNThe GH APIs are asymmetric, in that "get-commits-for-pr" is simple and always works, but "get-pr-for-commit" is super complex
limited to 250 commits, but assuming it's the 250 most recent, it should always include the recent triggering commit:
And, we just fallback to search API if cache may be invalid.
We should be able to use cache from JS, but we need to install the package:
https://github.com/actions/toolkit/tree/main/packages/cache
@actions/artifact as part of the github-script · Issue #395 · actions/github-script
Metadata
Metadata
Assignees
Labels
Type
Projects
Status