workflows/hetzner: expose machine_count and server_type as dispatch inputs#291
workflows/hetzner: expose machine_count and server_type as dispatch inputs#291igorpecovnik merged 3 commits intomainfrom
Conversation
…nputs
The workflow advertised four runtime knobs (MACHINE, MACHINE_COUNT,
RUNNER_COUNT, PERIOD) in its original commit message, but none were
wired up — workflow_dispatch had no `inputs:` block and there's no
top-level `env:`, so `${{ env.MACHINE || 'cax41' }}` and
`${{ env.MACHINE_COUNT || '4' }}` always evaluated to the default.
That made the workflow name ("Enable 16 Hetzner ARM64 runners")
literally true — it was the only thing you could trigger.
First pass at unfreezing it:
- machine_count: choice of 1/2/4/8/16 (default 4). The matrix
generator now reads inputs.machine_count instead of env.MACHINE_COUNT.
- server_type: choice of cax41/cax31/cax21 (default cax41). Create +
Cleaning both pick up inputs.server_type. The action auto-falls
back to a smaller server type on capacity shortage regardless,
so this is really "biggest you're willing to wait for".
`|| '<default>'` fallbacks are kept so repository_dispatch / API
callers that omit inputs still behave like the legacy call shape.
RUNNER_COUNT and PERIOD stay hardcoded for now; wiring those is a
follow-up.
Workflow renamed to drop the "16" — it's now variable.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 25 minutes and 20 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe workflow now accepts configurable inputs via manual dispatch: Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
The Hetzner runner workflow advertised four knobs (
MACHINE,MACHINE_COUNT,RUNNER_COUNT,PERIOD) in its original commit message but none were actually wired up —workflow_dispatchhad noinputs:block, so${{ env.MACHINE || 'cax41' }}and${{ env.MACHINE_COUNT || '4' }}always evaluated to the default and the workflow name ("Enable 16 Hetzner ARM64 runners") was literally the only thing it could do.First pass at making it configurable:
machine_count— choice of1/2/4/8/16, default4. Matrix generator now readsinputs.machine_count.server_type— choice ofcax41/cax31/cax21, defaultcax41.CreateandCleaningboth pick it up. The action auto-falls back to a smaller type on capacity shortage, so this is "biggest you're willing to wait for".|| '<default>'fallbacks are kept sorepository_dispatch/ REST API callers that omit inputs keep working as before.Workflow renamed to drop the "16" — it's now variable.
Out of scope (follow-ups)
RUNNER_COUNTandPERIODare still hardcoded; wiring those is a separate pass.armbian-config/HETZNER_RUNNERtoken investigation; not a workflow-shape problem.Test plan