Does Deleting an ARC 0.15 Runner Stop Its Active Job?
An ARC 0.15 runner gets marked for deletion during an upgrade while it is halfway through a build. What happens to that job, and how long does cleanup wait?
- ARC 0.15.0 can defer runner cleanup when Actions says its job is still running.
- The 30-second retry interval is not a deadline for the job to finish.
- Direct pod deletion and a 0.14-to-0.15 migration require separate decisions.
Deleting the runner resource need not immediately delete its pod
An EphemeralRunner is the resource ARC manages; the pod is where the build actually runs. In the 0.15.0 controller’s deletion path, a finalizer keeps cleanup under controller control. If deregistration of a live pod’s runner returns JobStillRunningError, reconciliation returns without deleting the pod and is scheduled again after 30 seconds.
That is a retry interval, not a 30-second job timeout. A runner remaining during deletion may therefore be waiting for work to finish. The delay alone does not prove either successful draining or broken cleanup.
Deleting the pod starts a different shutdown sequence
The live-pod check excludes a pod that is already terminating or has finished. If you delete the pod directly, ARC does not wait for its job to finish through this path.
Kubernetes terminates pods through stop signals and a grace period, followed by forced termination of remaining processes. That sequence does not wait indefinitely for a CI job. Removing the node that hosts the workload also falls outside ARC’s deregistration protection.
| Operation | What controls the outcome |
|---|---|
| Controller-managed EphemeralRunner deletion | The live-pod check and Actions’ response to deregistration. |
| Direct runner-pod deletion | Kubernetes pod termination and its grace period. |
| Controller and chart migration | Version-specific cleanup and CRD changes as well as runner state. |
Setting both runner limits to zero stops new pod creation
GitHub’s queue-draining example sets both limits explicitly:
maxRunners: 0
minRunners: 0ARC then creates no new runner pods for newly assigned work. This is a different milestone from finishing existing jobs or completing resource cleanup. The listener’s gha_busy_runners counts registered runners executing jobs; gha_running_jobs includes queued work. A zero busy count is not, by itself, evidence that every resource has been removed.
For maintenance, check job completion and then resource cleanup. Neither observation turns a subsequent direct pod deletion into an ARC-managed drain.
The 0.15 announcement does not make 0.14 migrations disruption-free
The October 1 release announcement describes in-place resource updates for patch upgrades. Moving from 0.14.2 to 0.15.0 is a different version transition.
In an October 6 issue, operator jedi-tal reported old runner sets remaining in Terminating after updating the controller and scale-set charts together through Argo CD. The reporter attributed the leftovers to the old finalizer name. A legacy cleanup problem is not the same as a live runner waiting for its job.
GitHub’s documented upgrade sequence removes scale-set installations, waits for cleanup, removes ARC, handles changed CRDs and reinstalls. Helm’s CRD lifecycle limitations explain why replacing chart values alone is not the full migration plan.
Name the object being replaced before choosing a maintenance procedure. The confirmed wait behavior belongs to a particular runner-deletion path in 0.15.0; it is not a blanket guarantee for controller upgrades, runner-image changes or node shutdowns.