Building iOS and macOS apps requires reliable CI/CD infrastructure, but managing self-hosted GitHub Actions runners at scale introduces friction. When your runner coordinator restarts, whether due to an upgrade, a pod reschedule, or a node hiccup, you need confidence that in-flight jobs continue, that queued work stays queued, and that abandoned VMs don't pile up consuming cluster resources. Version 1.1.14 of the Orka GitHub Actions Integration addresses these pain points with runner scale set reuse, automatic VM reconciliation, smarter provisioning tracking, and retry logic.
With collaboration with the community, we have made some improvements that bring the integration closer to being the infrastructure that stays out of your way.
What the Community Feedback Told Us
Before v1.1.14, the integration recreated the runner scale set on every restart. This sounds like a safety measure as it introduces a start fresh and avoids state confusion. But it created real problems in production:
- Orphaned VMs: When the integration restarted, existing Orka VMs from the previous run were left behind, ignored by the new scale set. These VMs kept consuming CPU, memory, and license resources until someone cleaned them up manually.
- Stuck jobs: GitHub Actions jobs assigned to the old scale set would hang in Pending status because the scale set no longer existed. Teams had to manually cancel jobs and rerun them, breaking the "fire and forget" workflow pattern.
- Overprovisioning: The integration had no visibility into VM deployments that were already underway, so a spike in job demand could spin up more VMs than the queued work actually needed.
These issues forced operators to monitor the integration closely and intervene manually—the opposite of what a reliable automation tool should do.
What's New in v1.1.14
Runner Scale Set Reuse
The integration now reuses an existing runner scale set instead of recreating it on startup. This means in-flight and queued jobs continue uninterrupted across a restart. When the integration stops, the scale set stays in place on GitHub, ready for the next run.
Reuse is the new default. No configuration changes are needed. If you prefer the previous lifecycle, where the integration deletes and recreates the scale set on startup and removes it on exit, set the MANAGE_RUNNER_SCALE_SETS environment variable to true.
VM Reconciliation on Startup
The integration now reconciles existing Orka VMs on restart by scanning for VMs with a matching name prefix. Running VMs are adopted into the new state and cleaned up when their jobs finish. Failed or non-running VMs are cleaned up immediately.
Reconciliation is controlled by the ENABLE_RECONCILIATION environment variable (default: true). The result is a clean slate: no orphaned VMs consuming resources, and no stuck jobs waiting for scale sets that no longer exist.
Smarter Provisioning Tracking
The integration now tracks in-flight VM deployments, giving it visibility into what is actually being provisioned. When demand spikes and job requests flood in, this tracking prevents the integration from spinning up more runners than necessary. The system knows which deployments are already underway and avoids redundant provisioning.
Automatic Retry on Download Errors
During runner setup, transient network issues could cause downloads to fail permanently. The integration now retries automatically when curl encounters temporary errors, improving resilience against brief network hiccups and flaky external resources.
Built with the Community
These improvements did not happen in isolation. Community members ran the integration in production, hit real problems, opened issues describing orphaned VMs and stuck jobs, and contributed pull requests that shaped this release. The fixes for scale set reuse, VM reconciliation, and provisioning tracking all came out of this collaboration.
We believe that tools built in the open, informed by real-world usage, are stronger. Your feedback, bug reports, and code contributions make the integration better. If you are running the integration or considering it, please bring your experience to the GitHub repository: report issues you encounter, open pull requests for features you need, and share feedback on what is working and what is not. The community contribution process is open at the orka-github-actions-integration repository.
Upgrading to v1.1.14
Upgrading is straightforward. Pull the latest Docker image, verify no active CI jobs are running, stop the previous instance, and start the new version.
The new behavior is on by default, no environment variable changes are required. Reconciliation can be turned off with ENABLE_RECONCILIATION=false, and the previous delete-and-recreate scale set lifecycle is available with MANAGE_RUNNER_SCALE_SETS=true.
The Bottom Line
Reliable CI infrastructure means fewer manual interventions, fewer orphaned resources, and more time spent on what matters: building great software. Version 1.1.14 brings the Orka GitHub Actions Integration closer to that goal by keeping the integration stateful and resilient across restarts, reconciling VMs automatically, and tracking provisioning more accurately. It is infrastructure that works in the background without demanding your attention.