You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past, I have noticed that if we run two (or more) "integration test" jobs at the same time, we are more likely to hit these throttling. Therefore, we enforce a global lock on the integration tests. This means that if one integration tests job is running, all other integration tests jobs must wait. So in this case, there may be an existing integration job running on the master commit, or maybe on the tag. So your PR's integration job is stuck waiting for that job to finish so that your PR can take the global lock.
The text was updated successfully, but these errors were encountered:
There's a global lock on the integration tests.
Background:
The integration tests for AutoMerge do a lot of actions such as "create a PR". GitHub applies secondary rate limits to these "create content" API calls (https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits) - these secondary rate limits are in addition to the regular ("primary") rate limits. If we are making too many of these API calls at the same time, then GitHub will further throttle us as an abuse prevention mechanism.
In the past, I have noticed that if we run two (or more) "integration test" jobs at the same time, we are more likely to hit these throttling. Therefore, we enforce a global lock on the integration tests. This means that if one integration tests job is running, all other integration tests jobs must wait. So in this case, there may be an existing integration job running on the master commit, or maybe on the tag. So your PR's integration job is stuck waiting for that job to finish so that your PR can take the global lock.
The text was updated successfully, but these errors were encountered: