Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Add Fine-Tuning section for GitHub runner scaler #1535

Merged
merged 2 commits into from
Feb 12, 2025
Merged

docs: Add Fine-Tuning section for GitHub runner scaler #1535

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a2861de
docs: Add Fine-Tuning section for GitHub runner scaler
silviu-dinu Feb 12, 2025
a4ba77b
docs: GitHub runner scaler features version clarification
silviu-dinu Feb 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions content/docs/2.17/scalers/github-runner.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,16 @@ Note: This does not apply to a hosted appliance as there are no rate limits.

Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.

**Fine-Tuning**

The current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters.

For example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly.

*Older versions of this scaler can fetch only 30 workflow runs and 30 jobs per run during each polling cycle. More details available on this [thread](https://github.com/kedacore/keda/pull/6519).*

At the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call.

**References**

GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)
Expand Down
Loading