Hitting secondary rate limits and other errors when fetching tags

[YJDoc2]

When using this action for generating a tag PR, we are getting error

GET https://api.github.com/search/issues?q=repo%3Acontainers%2Fyouki+is%3Apr+is%3Aclosed+13d791b+c98c0ca+a51c03a+33e417f+496d955+cfa2ea9+919ff4a+762a2e8+701085d+9e35012+ae48534: 403 You have exceeded a secondary rate limit. Please wait a few minutes before you try again.

Corresponding CI run : https://github.com/containers/youki/actions/runs/8554693630/job/23440530901

Also, When this was run on a PR merged by dependabot, it errored with

POST https://api.github.com/repos/containers/youki/releases/generate-notes: 403 Resource not accessible by integration []

Corresponding CI run : https://github.com/containers/youki/actions/runs/8548546699/job/23438881389

Is there anything that can be done on our side to fix this issue, or any changes needed in this action itself?

Thanks!

[gteufelberger]

Same here in https://github.com/aris-space/helios-procedures/actions/runs/8940367533

Did you ever resolve this? Looking https://github.com/containers/youki/blob/30e3ab5c2d42fbbe621a1add1841218f566ee898/.github/workflows/tagpr.yaml I assume you are still using the action.

[YJDoc2]

Hey, unfortunately I haven't yet found any way to resolve this. The best is I wait for a few minutes, hoping that the timeout for the rate limit passes and manually re-run it. (yes, we are still using this action).

@Songmu , can you help out , suggesting what can be done. If you can suggest any solution, I'd be happy to try and contribute the fix.

[snaka]

The same problem sometimes occurs in my repositories, and I have been dealing with it by manually retrying.

A quick look into “Secondary Rate limit” turned up the following information.

https://github.com/gofri/go-github-ratelimit

https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits

I am guessing that these may be the solution, but at this point I cannot be sure.

[snaka]

After repeating the experiment several times, we noticed an interesting fact.

I noticed that tagpr's own workflow used create-github-app-token to generate a Token, so I did the same for my repository, which was having problem, and the problem was solved.

tagpr/.github/workflows/tagpr.yaml

Lines 14 to 30 in a667113

	- name: Generate token
	id: generate_token
	uses: actions/create-github-app-token@v1
	with:
	app-id: ${{ secrets.APP_ID }}
	private-key: ${{ secrets.PRIVATE_KEY }}
	- name: checkout
	uses: actions/checkout@v3
	with:
	token: ${{ steps.generate_token.outputs.token }}
	- name: tagpr
	run: |
	make install
	echo '::echo::on'
	tagpr
	env:
	GITHUB_TOKEN: ${{ steps.generate_token.outputs.token }}

Now it seems to work more stable than when using secrets.GITHUB_TOKEN as mentioned in the README.

I'm not sure if this is a tagpr issue or a GitHub API issue, but I was able to work around the problem with the above.

However, I don't think this is a very common method because it requires a GitHub App to be prepared for deployment.
I believe there is a better solution. (I think it is probably go-github-ratelimit now)

[snaka]

@YJDoc2

• Retry when "Secondary rate limit" error occurs in GitHub API #183

The above PR addresses the Secondary Rate Limit error by implementing retries. However, it does not address the other error.

If necessary, please create a separate issue for the remaining error.

[YJDoc2]

@snaka thanks a lot for your investigation and fix! I haven't seen the second issue in a while, I'll create a new issue if needed. Thanks!