Don't Remove Support to `--once`

On PR #660, the --ephemeral flag was introduced with the intent of replacing the --once flag. But by deregistering and reregistering the runner every time, the number of API calls to GitHub dramatically increases, and eventually, the rate limit is exceeded.

I experienced before the --ephemeral even existed. Every time I wanted to run a job, I was registering a new runner, starting it with --once, and deregistering it after the job was completed. Quickly the maximum number of API calls allowed to a GitHub App was exceeded. I solve the problem by keeping the credentials of runners and only registering and deregistering runners on upscale and downscale operations.

With the removal of the --once flag, it will not possible to run a single job on the runner without removing it when the job is completed. Effectively limiting the number of ephemeral runners that can be used within an hour. Using a PAT, you are limited to 2500 jobs run by a self-hosted runner, assuming the only operations you do are runner registration and deregistration. With a GitHub App, in the best case, you will be able to run 6250 jobs, or 7500 with GitHub Enterprise Cloud, which is not reasonable for a lot of companies.

@TingluoHuang @pje

[MichaelJJ]

@thboop Does the endpoint limit count for enterprise, organization and repo registration tokens?

I’ve tested all 3 and I see 0 used for actions_runner_registration but the core used count increases instead.

[thboop]

Hey @t0rr3sp3dr0 ,

Thanks for the feedback here. A few things our team is working on:

• We aren’t going to remove --once flag just yet. Our team views ephemeral as the future, but we want to ensure we don’t break your current workflows as we move towards it
• We are looking into possibly providing a separate rate limit for the runner registration endpoint with a higher value, it wouldn’t count against your normal rate limit quota. Rate limits allow us to prevent malicious users from doing denial of service attacks, but we want it high enough to not impact legit usage. I’ll follow up with more exact details on numbers here in the near future.
• We are working on updating our docs with best practices to manage a pool of ephemeral runners, we will touch on caching and how to manage tokens in those docs. Typically this is an operator pattern, as you are already using on linux. Our macOS machines get a token passed in in a similar pattern

Please follow up if you have any questions or concerns, and we appreciate the feedback!