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.

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

Note about capping deployments to ~100 replicas #1103

Merged
merged 2 commits into from
Mar 16, 2022

Conversation

Djiit
Copy link
Contributor

@Djiit Djiit commented Feb 9, 2022

Fixes #1101

README.md Outdated Show resolved Hide resolved
@toast-gear
Copy link
Collaborator

Let me have a think about the best way to document this. In the future we want Stateful Runners to take a more prominent place in the docs and this will be relevant to them too.

@toast-gear
Copy link
Collaborator

toast-gear commented Feb 14, 2022

I think it's probably best to put it as a second > note after:

> Since the release of GitHub's [`workflow_job` webhook](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job), webhook driven scaling is the preferred way of autoscaling as it enables targeted scaling of your `RunnerDeployment` / `RunnerSet` as it includes the `runs-on` information needed to scale the appropriate runners for that workflow run. More broadly, webhook driven scaling is the preferred scaling option as it is far quicker compared to the pull driven scaling and is easy to setup.

Additionally could could you change it to:

> If you are not using GHES, and so can't set your rate limit budget, it is recommended to have fewer than 100 replicas per deployment to avoid exhausting your budget.

Cheers pal

Copy link
Contributor

@genisd genisd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not that I have anything to say. as a symbolic gesture here is my approval :)

@toast-gear
Copy link
Collaborator

toast-gear commented Mar 2, 2022

This hasn't been merged on purpose, it will get merge after the next release which is imminent. The next release includes caching of requests so this warning won't hold true. It will need to highlight this applies to controller version < v0.22.0 in the style of the other version warnings:

> If you are using controller version => [v0.22.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.22.0) and you are not using GHES, and so can't set your rate limit budget, it is recommended that you use 100 replicas or fewer to prevent being rate limited

Merging it now will just cause confusion and will need updating as soon as the next release is out.

@mumoshu mumoshu force-pushed the master branch 2 times, most recently from ac017f0 to 25570a0 Compare March 3, 2022 02:05
@toast-gear
Copy link
Collaborator

@Djiit there were various changes to the readme for the latest release. If you could resolve the conflicts in this PR and change the message to be the below we can get this merged:

> If you are using controller version < [v0.22.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.22.0) and you are not using GHES, and so can't set your rate limit budget, it is recommended that you use 100 replicas or fewer to prevent being rate limited

@Djiit
Copy link
Contributor Author

Djiit commented Mar 16, 2022

@toast-gear something like this ?

@toast-gear toast-gear merged commit c06a806 into actions:master Mar 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

High API Calls quota consumption
3 participants