Issue with Secondary Rate Limit about cascading-downstream-merge HOT 4 CLOSED

We haven't run into those secondary rate limits on our end before. Those rate limits are also hard limits set by GitHub with no ability to change them. I know because we've asked before without much success. A couple questions I have are how many total branches are in the repo? Are you also using the a token generated by a github app or a machine users? A machine user typically hit the rate limit much quicker than an app as well.

Check out the recommendation in: https://actionsdesk.github.io/cascading-downstream-merge/#/installation

from cascading-downstream-merge.

@jdesulme thanks for the response.

I have it set up through an app following the example yml file found at https://actionsdesk.github.io/cascading-downstream-merge/#/installation?id=leveraging-an-additional-merge-token-to-enable-commits-to-protected-branches only updating the "cascading-downstream-merge" to the latest version of 1.2.0.

If I change it to be an Machine User token then I don't need the "action-github-app-token" app and can pass the generated token directly to the "GITHUB_TOKEN" for the "cascading-downstream-merge"?

from cascading-downstream-merge.

I did try out the personal access token and ran into the same Secondary Rate Limit. It is weird with the 1.2.0 it fails before it even attempts the first merge, but if I try the old version 0.1.4 it merges everything and complains about the Secondary Rate Limit after it is already done.

from cascading-downstream-merge.

i changed directions and made my own.

from cascading-downstream-merge.