StatefulSet's RollingUpdate replaces Pods one at a time in strict
sequence (unlike a Deployment, and unaffected by podManagementPolicy:
Parallel, which only governs initial scale-up/down) -- confirmed live:
run #152 restarted correctly (2/3 pods updated, then the 3rd) but hit
the old 120s ceiling before the last pod turned Ready, so CI reported
"failure" for a rollout that actually completed successfully seconds
later. 300s gives enough headroom for three sequential pod cycles
(image pull + start + native-Cluster rejoin) instead of tuning it to
the exact observed timing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
im-server moved from Deployment to StatefulSet in im-deploy-config
(native Cluster enablement) -- this workflow's kubectl commands still
targeted the old resource type, so every deploy since the migration
failed at the final step with "deployments.apps im-server not found"
(image built/pushed fine, just never got rolled out).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Old VM's blue-green im-server is decommissioned. App config
(MySQL/Redis/API key/admin-internal secrets) now lives in the
cluster's own Deployment manifest, not injected through CI --
this workflow's job is just build (from source, via
docker/tinode/Dockerfile.build as before), push under :test,
and roll the deployment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
richjohnrambo