Excessive API call usage

[anomiex]

It appears that the recommended configuration for this action will make 11 calls to the GitHub REST API per push and per language, which can add up quickly and make it too easy to reach the rate limit of 1000 calls per hour with the default Actions token.

• getWorkflowPath() makes two calls, and seems to be called twice from github/codeql-action/init@v1.
  • It looks like one is constructing a cache key like ".github/workflows/filename.yml:jobid".
  • The other seems to be linting the job definition?
• github/codeql-action/init@v1 then makes two calls to update the status.
• github/codeql-action/autobuild@v1 also makes two calls to update the status.
• github/codeql-action/analyze@v1 makes another two calls to update the status, plus one more in between to actually upload the results.

I'd expect just two or three calls to actually be needed: one (maybe) to update the status to "working" at the start, one to upload the results, and one to update the status to "completed" at the end.

If the cache key and linting are needed, could you convince the Actions team to supply the workflow file path via an environment variable or context property so you don't have to make two API calls to fetch it? It looks like they already conditionally provide this information in github.workflow (and maybe also GITHUB_WORKFLOW) if the workflow yaml file doesn't name the workflow itself.

FYI, this came up when I was working with GitHub Developer Support to try to figure out why we kept hitting the API rate limits, and I noticed that this action was responsible for a significant fraction of the calls. The support person suggested I report it to you directly.

[aeisenberg]

Thanks for raising this issue. We haven't put much effort into minimizing API calls since this is the first we've heard that it can be a problem. With this in mind, we're doing a review of all the calls and seeing if there are some that can be dropped or merged.

With that in mind, are you running the code scanning workflow on every push to any branch? Our recommended setup is to run on push to the default branch, and also on pull request.

[anomiex]

No. We're running it on pushes to master, pull requests targeting master, and a weekly cron. But since most of our pull requests target master and most of our pushes are updating PRs, that still winds up running on most pushes.

You can see our workflow yourself here.

P.S. You may want to review your documentation at https://github.com/github/codeql-action#usage, it shows a configuration that does run on every push and PR.

[chrisgavin]

Hi @anomiex. We've made some changes to how our API rate limiting works that should hopefully help here. Specifically, calls to update the analysis status are fairly cheap so we have decided to exclude them from the normal API rate limiting. I hope this helps lessen the concern about CodeQL Action requests using up too much of the rate limit quota for your Actions token.

Hopefully we can also make more improvements in this regard in future; as you've suggested, having the workflow file available on the runner rather than having to fetch it from the API would seem very useful.

[jsoref]

Fwiw, the fact that github.workflow is unreliable is a real thorn in my side. It'd be really nice if this team could tell the actions team that it should be published as a reliable variable (GITHUB_WORKFLOW_PATH) so that the rest of us could benefit from not having to beg.

[adityasharad]

Thanks for the feedback: as I understand it, the request is to expose an Actions context value and environment variable that consistently returns the full path to the workflow file within the repo, unlike github.workflow/GITHUB_WORKFLOW which returns the workflow name if there is one and the file path otherwise. We'll pass that on.

We have no further planned work on reducing API call usage after #567 (comment), and will remain careful to avoid introducing unnecessary API call overhead in future. With that in mind, I am closing this issue, but please file fresh issues for us if you encounter further trouble with API limits and we will be happy to investigate.