Hello all!
So I’ve enjoyed working on parts of Caddy the past few weeks, mainly on bugfixes and tinkering around with some new plugin ideas. I found myself having to build and test Caddy with different permutations of plugins and operating systems fairly frequently. Combine this need with some recent discussions around the future around caddy {add|remove}-package
commands and it appeared that this might be useful in a few different cases. Some folks also asked about standing up their own build servers.
So I wrote one and tossed it up at GitHub - Compy/prox-builder: A distributed Caddy binary build server (I would’ve called it something like Caddy-builder or CaddyTron9000 but I didn’t want to risk stepping on any Trademark toes). It’s Apache 2.0 licensed, so feel free to go and do Apache 2.0 things with it.
What it does
- Runs as a single binary or distributed amongst a hub process and 1-many agent processes
- Wraps xcaddy functions
- Allows you to specify a base Caddy version when compiling
- Relays build log information back to you in realtime via websocket (no external dependencies like Pusher)
- Caches builds based on a key of {arch,os,caddy version,sorted package list} so that duplicated builds are returned immediately (great for CI)
- Features a lightweight UI (HTML/CSS/JS all roughly under 130kb), embedded directly into the go binary
What it doesn’t do (yet)
- S3 storage, but I’m working on it
- Update the “available Caddy versions” and latest commit SHA on regular intervals so that locally cached binaries are evicted appropriately
- Storage pruning - serving tons of builds over local storage can quickly chew up disk space. We should consider culling based on a storage threshold being breached.
- Work with
{add|remove}-package
commands. Ideally we want to support specifying and endpoint with that command. Though if the argument is made to keep things immutable with respect to suggested Caddy deploys, this can be stricken.
Demo
I threw a demo of it up at https://builder.prox.sh - It’s actively mirroring Caddy’s package list. However be warned, it’s running on dev hardware. If you point your CI stack at it, finger wagging will ensue.
I’ll be cleaning up the code and squashing some bugs.
Tiny Caveat
This runs with an altered version of xcaddy
- I had to modify the core builder and environment structs to support passing a custom Logger via the context. This is solely for relaying build logs through websockets. We use a custom logger here per build job so that multiple websocket+build sessions don’t experience cross-talk. Those modifications are here.
Maybe this will be useful for someone!
Jimmy