Limits and GitHub API use
How many evaluations a commit costs, how Prodgator shares your GitHub rate limit, and the hard limits for pull request gates.
Cost and GitHub API use
A typical commit sees about 3 to 8 evaluations: the push itself, one or two review events, CI checks finishing, and attestations arriving, with events close together combined by the 10-second wait above. Each evaluation makes about 5 to 10 GitHub requests before caching; a cache keeps a GitHub response for a head commit for a day, so repeated reads within that day cost nothing.
GitHub reads for pull request gates share your installation's hourly rate limit with everything else Prodgator does for it. Prodgator keeps a budget per installation so pull request gates cannot use it all. Once that budget is spent for the hour, evaluation waits for it to reset instead of exceeding the limit. The check itself is left showing its last result during the wait; the deferral does not appear as check text, only in Prodgator's logs and metrics.
GitLab API use
A merge request evaluation makes about five GitLab requests with the connection's token (the project, the merge request, its approvals, its diffs and the commit statuses; one more for a fork's source project) plus one to post the status. gitlab.com allows 2,000 authenticated requests a minute per user, shared by everything the person who connected the group does through the API, so there is no budget to keep. If GitLab answers 429, the evaluation is retried a minute later. Reads are not cached between evaluations.
Bitbucket API use
A pull request evaluation makes about five Bitbucket requests with the connection's token (the repository, the pull request, its head commit, its diffstat and the commit's build statuses) plus one to post the build status. Bitbucket Cloud limits API requests per user per hour, shared by everything the person who connected the workspace does through the API. If Bitbucket answers 429, the evaluation is retried five minutes later. Reads are not cached between evaluations.
Azure DevOps API use
A pull request evaluation makes about five Azure DevOps requests with the connection's token (the pull request, its iterations, the changes of the latest iteration, and the statuses on the head commit and on the pull request) plus one to post the status and one or two for the policy comment. Azure DevOps limits usage per organization and user. If it answers 429, the evaluation is retried a minute later.
Limits
| Limit | Value |
|---|---|
| Policies governing one pull request | 20 |
| in the input | 100 |
| in the input | 100 |
| in the input | 300 |
| in the input | 100 |
| Automatic evaluations per head commit | 50 |
| Evaluations per organization per hour | By plan; see Plans and features |
| Repositories with a pull request gate on the Free plan | 1 |
When more than 20 policies would govern one pull request, Prodgator evaluates none of them and the check waits; remove bindings until 20 or fewer apply.