Talos compatibility guard is skipped on pull requests and only fails in the merge queue #3624

🤖 Generated by the Agentic Engineer

Evidence

The check that decides whether a Kubernetes version bump is admissible does not run on the pull request that proposes it. It is filtered out by path detection and runs only in the merge group, so the failure appears after the change is already queued.

Measured on #3534 (update Kubernetes to v1.37.0), 2026-09-06:

The merge-group failure is a true finding, not a flake:

ksail.prod.yaml: Kubernetes v1.37.0 is not verified compatible with Talos v1.13.9:
version of Kubernetes 1.37.0 is too new to be used with Talos 1.13.9.

Affected audience and impact

Any update that changes the Kubernetes version reaches the queue looking fully ready and is then evicted. The pull request shows no signal at all about why, so it sits indefinitely: #3534 was open and apparently merge-ready for three days with auto-merge never armed.

The cost is worse than a delay. Eviction is the only feedback, so the natural response is to re-queue, which reproduces the same failure and consumes a full merge-group deploy cycle each time. The guard exists and is correct — it simply runs where it cannot prevent the wasted cycle.

Expected behaviour

A change that the Talos compatibility guard would reject fails on the pull request, before it is ever queued.

Acceptance criteria

• The compatibility validation runs on pull_request for any change that alters the Kubernetes or Talos version, rather than being filtered out by path detection.
• A pull request proposing an incompatible pair reports a failing check on the pull request itself.
• The merge-group run keeps the guard as well, so nothing weakens the final gate.

Rough size: small.

Observed while driving #3534.