CAPI Scaleway 0.3.0 ships a new runner dispatch model and a set of reliability fixes for Tuist’s macOS runners.
Shared warm pool
- GitHub Actions runners on Tuist’s Mac mini fleet now use a shared warm pool with dispatch-time binding. One host fleet backs multiple image pools, and you route jobs by pool labels. Per-account concurrency is controlled by a single
runner_max_concurrentsetting.
Reliability
- Runner hosts recover from bootstrap regressions that previously caused empty sudo passwords, looping firewall errors during host setup, or duplicate Scaleway host adoptions.
- Orphaned workflow jobs are now automatically re-queued if a runner pod claims a job but never registers with GitHub, so jobs no longer sit in GitHub’s queue for hours.
- Stale terminating macOS pods are force-completed after Tart VM cleanup, preventing them from blocking future rollouts.
- Fleet-spread updates wait for a Deployment to settle before stamping a new fleet hash, avoiding competing ReplicaSets during Helm rollouts.
Observability
- Oban job metrics are restored in Grafana Cloud, and xcresult-processor pods are now scrapable. A new dashboard tracks processor health, throughput, and latency.