A quick note on my ASU builder changes
Operational changes that made my OpenWrt ASU builds more reliable when the official builders were overloaded.
- Making local OpenWrt ASU builds more reliable when official builders are overloaded.
- Container inspection, retry behavior, and diagnostics for early exits and exec races.
- TTL behavior and CORS support for browser-facing tooling.
- Configurable container network mode and the tradeoff of slow Raspberry Pi cross-compilation.
I started this work because the official OpenWrt build servers were overloaded and I needed my own ASU builds to finish reliably.
That pushed the changes toward operations, not feature work. The useful parts were better container inspection, retry logic for transient exec failures, clearer diagnostics when a build dies early, TTL changes so results stay around long enough to matter, and CORS support for browser-facing tooling.
One part of the work was around container execution and failure visibility. The builder was already doing the hard part of isolating image builds, but the more interesting problem was what happens when a container exits early, when an exec call races the container state, or when the failure is real but the logs are not easy to see from the place the error first appears. That led to changes around container inspection, retry behavior for transient exec failures, and better diagnostics when something dies before the build step you expected to run.
The two changes that felt most important were the TTL adjustments and the CORS support. The TTL work matters because builds are not cheap, especially when you are trying to keep results around long enough to be useful without letting failures linger longer than they should. The CORS change was simpler, but it removes unnecessary friction for browser-facing tooling that needs to talk to the API cleanly.
I also touched some of the surrounding operational details. That included making the container network mode configurable instead of assuming one path, and tightening the behavior around container inspection, retry logic, and diagnostics when exec calls fail or a build container exits earlier than expected.
This is the kind of repo where those details decide whether the service stays understandable when it breaks. It is package selection, worker behavior, caching, container boundaries, API expectations, and the reality that the systems depending on it are usually constrained enough that clean upgrades matter.
One of the clearer lessons from the work was that cross-compiling on Raspberry Pis can be very slow, but slow and available is still better than unavailable. That is a useful reminder in this kind of environment. Sometimes the goal is not elegance. It is having a path that works when the nicer path is saturated or out of reach.
That is the thread I keep getting pulled toward: software that stays close to the machine, close to the operational constraints, and close to the point where small implementation details decide whether the whole thing feels reliable.