GitHub Commit API throttling prevents successful completion

calibreapp / image-actions

A Github Action that automatically compresses JPEGs, PNGs and WebPs in Pull Requests.

https://calibreapp.com/blog/compress-images-in-prs

GNU General Public License v3.0

1.42k stars 67 forks source link

GitHub Commit API throttling prevents successful completion #32

Open pelikhan opened 4 years ago

pelikhan commented 4 years ago

First thank you for this great action; it's very useful!

I am facing an issue in trying to enable this action in a project with a large set of existing images (1000+). The first PR using the action generates a lot of GitHub API calls which hits API throttling limits (the error is silently swallowed btw).

https://github.com/microsoft/pxt-microbit/commit/89983dafb205dfbf627bbc9f066b58436196fa6c/checks?check_suite_id=321921856#step:4:918

Is there a way to run the image optimization locally to "bootstrap" an existing repository?

pelikhan commented 4 years ago

Update: it went through on a subsequent build.

benschwarz commented 4 years ago

Hey @pelikhan, thanks for logging this.

This has come up before and it wasn't really addressed other than a general 🤷‍♂️ from me. That's mostly because GitHub actions was undergoing changes and we were waiting for it to settle down.

Here are some steps that we could take to improve the situation:

[x] Catch the error, log it better
[ ] Explore other ways of committing changes (using the git client directly?)
[x] PR #29 aims to add support for actions.yml. I know that @chabad360 is using that as a means to prepare image-actions to be run in other CI setups. Maybe we can come up with an 'offline' workflow that allows you to run it manually?

pelikhan commented 4 years ago

Supposedly, you could query https://developer.github.com/v3/rate_limit/ and wait till you are not rate limited.

Or have a configurable maxImagesPerCommit to simply cap the number fixed images.

Feels like local exec of GitHub actions is something GitHub should fix.

DeLongShot commented 3 years ago

For those who come here later, I have also observed this when trying to compress a lot of images.

In my case, I needed to compress a large group of images to start. As a workaround, I used a combination of ignorePaths and multiple PRs to break the large group of images into smaller groups to compress. For each PR, I would only compress a small group of images at a time. Then, I just opened multiple PRs until I had compressed every image.

Note: This was for a private repo for myself, so opening multiple PRs might not work well for a repo with multiple contributors.

Breaking it into smaller groups did the trick and I didn't have any errors after that. Not ideal, but worked out fine.