[0xmichalis]

Summary

• The reconciler (assessPods) and the webhook (standInReady) counted a stand-in as soon as its Ready condition turned true. The Deployment and Rollout controllers only count a pod as available once it has been Ready for minReadySeconds, and workloads set it to keep the old pod around while the new one finishes warming up. Understudy admitted the eviction before that window ended, so a disruption handover was shorter than the one the workload's own rolling update guarantees.
• Add Target.PodAvailable, which applies the controllers' rule (Ready since a known time, for longer than the target's spec.minReadySeconds), and use it in both places. Targets without minReadySeconds behave exactly as before.
• Docs: how-it-works step 4.

Verification

• Unit table for PodAvailable over Deployment and Rollout targets: no Ready condition, not ready, ready without minReadySeconds, ready for less than / exactly / longer than minReadySeconds, ready since an unknown time.
• New envtest spec: with minReadySeconds: 30, a freshly Ready stand-in keeps the hold (429, phase Surging); once it has been Ready for 31 s the phase becomes Releasing and the eviction is admitted. On main it released immediately.
• make test lint build and the ARGO_ROLLOUTS_CRD= "Optional Rollout API" run: passed, no generated-file drift.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.