>Caching with Swatinem/rust-cache. It helps, but there’s a trap. A workflow run can only restore caches from its own ref or the default branch, and GitHub evicts caches unused for 7 days.
>A self-hosted runner for the heavy builds. This was by far the biggest win, 90 minutes down to 40. It also means I now maintain a build server.
WarpBuild (https://www.warpbuild.com/)[1] solved this for me.
1. You can cache into your own s3 bucket, so you manage eviction policy
2. They manage the infrastructure, or you can link in your AWS account. I have builds that run on spot instances that are requested when a build starts.
Then for the caching issue, I just have a scheduled job that reruns a build at midnight on the master branch.
[1] Not affiliated, found them through Google several months ago
since claude wrote this article and probably the app as well, i would reccomend asking claude to use sccache in ci to cut down on compile times.
Your LLM can replace your cargo build with bazel in a few sessions. Queue the bazel-haters on HN...
The rust support has gotten really good, and the maintainer for the rust rules works at OpenAI, which, incidentally, is how at least parts of OpenAI builds rust and wasm: https://github.com/openai/codex/blob/main/MODULE.bazel.
I have a pretty complex rust backend in my project. I rent a capable bare-metal build server that costs about $150/mo that powers all my personal CI. All it does is start a systemd service for gh actions self-hosted runner. I can build and release this project in around 2-4 minutes, where before even a local dev iteration cycle would be up to around 10 minutes, much less building and releasing the whole thing, which was around an hour.