Fork 0
A small rust program that uses the Hetzner and Woodpecker/Drone APIs to enable starting servers to run CI tasks for.
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Go to file
ljoonal d5fcfb2649
ci/woodpecker/push/woodpecker Pipeline was successful Details
Fix spelling of hetzner
5 months ago
src Fix spelling of hetzner 5 months ago
.dockerignore Initial commit 8 months ago
.gitignore Initial commit 8 months ago
.woodpecker.yml Woodpeckerify pipeline config 5 months ago
Cargo.lock 0.3.0 release 5 months ago
Cargo.toml 0.3.0 release 5 months ago
Dockerfile Better woodpecker compatibility 5 months ago
LICENSE.md Initial commit 8 months ago
README.md Fix spelling of hetzner 5 months ago
docker-compose.example.yml Fix spelling of hetzner 5 months ago
rustfmt.toml Initial commit 8 months ago


Hetzner CI autoscaling

A small rust program that uses the Hetzner's API along with Woodpecker / Drone to enable starting servers to run CI tasks for.

Note that scaling down currently only happens when there's no pending or running builds, as determining which runner has builds isn't doable with the current woodpecker / drone API. While some kind of a "nice" shutdown request method could be built for that, it was outside of my initial few hours implementation scope for this.

It's also set up to ramp up conservatively, and request a max 1 server per poll loop. So to summarize, it's made for small instances. If you need to do mass scaling you'd probably be willing pay Harness for their scaling solution anyways.

Or you might want to check out picus for Woodpecker, which I only found after already having implemented this. On a quick glance, I'd say the main differences are that this project is focused on being small & lightweight (at the time of writing, this project's docker image is less than 2MB). This project tries to avoid dependencies, and thusly the whole async rust ecosystem in general due to it usually resulting in larger executables. Whereas picus seems like it's got a bit more abstractions, tests, and options, whilst also using more crates & relying on async code, and thusly it'll probably be easier to adapt to other needs as well.


Run cargo run for local dev builds. For production usage I personally would recommend building the docker image yourself. See the docker-compose.example.yml file for the configuration env vars.

I do have the container image published to my own container registry, but I wouldn't recommend others to rely on it. Also to note that the latest tag is always updated directly whenever the CI build passes, so don't trust it to ever be stable. Breaking changes can and do happen, though I generally do try to respect Rust's semver. Additionally I don't really feel like writing a changelog file for this weekend project, but you can check the diffs (for example v0.2.0 vs v0.3.0)


Because the official implementation is not Open Source and doesn't work anyways with the latest Drone.IO OSS version. And because I used a private Gitea instance with Drone integration, where CI build jobs are very rare, and nowadays have upgaded it to Woodpecker and Forgejo. I don't personally run CI jobs that often, but when they do happen, they're usually quite bursty (tens of builds in a few hours). So instead of wasting my resources with upgrading my servers to account for the bursty nature... Thanks to Hetzner Cloud's hourly billing I can just pay a few cents for a way more powerful server only for the time I actually use it.

Note to self

Use the standard rust docker container images instead of my own custom one. Since bootstrapping the CI would be even more difficult if both the autoscaler and the CI image generation required each other.