Let the listener own the EphemeralRunner Running phase transition

[nikola-jokic]

Stacked on #4580. First of two PRs that split #4582 apart.

af55427f in #4582 bundled two unrelated things: a behavioural change to who
owns the Running phase, and a workqueue optimisation. This PR is the
behavioural half. The predicates follow separately so that an optimisation is
never reviewed together with a semantic change.

The problem

updateRunStatusFromPod derived EphemeralRunner.Status.Phase straight from
the pod phase, so a runner flipped to Running the moment its pod started,
whether or not it had picked up a job. Running therefore meant "the pod is
up", not "the runner is busy".

That matters for scale-down. newEphemeralRunnersByStates groups runners into
pending and running, and deleteIdleEphemeralRunners walks pending first
and running second. Because every started runner was Running, the two
buckets carried no information about which runners were safe to remove.

The change

The listener already knows exactly when a job is assigned to a named runner, so
the transition moves there:

• HandleJobStarted reads the runner first and only promotes it to Running
  when it is not Failed, Succeeded or Outdated and is not being deleted.
  The phase goes out in the same status merge patch as the job fields it
  already writes.
• The listener role gains get on ephemeralrunners for that read, split out
  from the existing ephemeralrunners/status rule so status keeps only
  patch.
• updateRunStatusFromPod still publishes the initial Pending phase while the
  pod starts, and no longer promotes to Running.

Runners waiting for work now stay Pending, so scale-down drains genuinely idle
runners before ones executing a job.

Note for review

The read and the patch are two calls, so a runner can reach a terminal phase in
between and still receive Running. The window is small and the ephemeral
runner set reaps terminal runners regardless, but it is worth a look if you want
this tightened with a resource version precondition.

Testing

go test ./controllers/... ./cmd/... with envtest, all green. New coverage:
TestHandleJobStarted in the scaler, plus envtest cases asserting the
controller does not set Running from pod status and that readiness still
tracks the pod.

[Copilot]

Copilot review overview

🟡 Changes recommended

Address the phase-transition race conditions and update the Running phase documentation.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Lite
Findings: 1 · 1

New issues introduced by this change (2)

Severity	Finding
	cmd/​ghalistener/​scaler/​scaler.go — The GET and this status merge patch are not tied by a resourceVersion precondition. If the runner…
	cmd/​ghalistener/​scaler/​scaler.go — This changes the public meaning of Running to indicate an assigned/busy runner, but the API type…

What changed in this PR

This PR moves EphemeralRunner’s Running phase transition from pod reconciliation to listener job assignment.

Changes:

• Adds listener reads and phase-aware status updates.
• Keeps pod reconciliation from promoting runners to Running.
• Updates RBAC and test coverage.

File	Review summary
controllers/​actions.github.com/​resourcebuilder.go	Adds listener read access for ephemeral runners.
controllers/​actions.github.com/​ephemeralrunnerset_controller_test.go	Covers listener-owned phase transitions.
controllers/​actions.github.com/​ephemeralrunner_controller.go	Retains Pending initialization; its phase write needs resource-version protection.
controllers/​actions.github.com/​ephemeralrunner_controller_test.go	Tests pod phase and readiness behavior.
cmd/​ghalistener/​scaler/​scaler.go	Sets Running on assignment; requires conditional updates to prevent terminal-state races and updated phase documentation.
cmd/​ghalistener/​scaler/​scaler_test.go	Tests listener phase transitions and job updates.

Suppressed comments (1)

controllers/actions.github.com/ephemeralrunner_controller.go:858

• This guard only observes the reconciler's cached object. If that read sees an empty phase, the listener can patch Running before this pod reconcile writes its status; the subsequent merge patch then includes Pending and can overwrite the listener-owned Running phase because it is not an optimistic-lock patch. Protect this initial phase write with a resource-version/refetch strategy so the controller cannot regress a phase that the listener has already advanced.

	phase := ephemeralRunner.Status.Phase
	if pod.Status.Phase == corev1.PodPending && phase == "" {
		phase = v1alpha1.EphemeralRunnerPhasePending
	}

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Critical and moderate correctness and concurrency issues remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Lite
Findings: 3 · 1

New issues introduced by this change (2)

Severity	Finding
	cmd/​ghalistener/​scaler/​scaler.go — Use the lowercase EphemeralRunner resource name
	controllers/​actions.github.com/​ephemeralrunner_controller.go — Stale pod reconciliation can reset the listener-owned phase

Pre-existing issues (2)

Severity	Finding
	cmd/​ghalistener/​scaler/​scaler.go — The GET and this status merge patch are not tied by a resourceVersion precondition. If the runner… View comment
	cmd/​ghalistener/​scaler/​scaler.go — This changes the public meaning of Running to indicate an assigned/busy runner, but the API type… View comment