Repository navigation
chore(relay-staging): declare staging C4 on image E so the director can deploy it - #27462
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The checked-in C4 target changes to E, while the live VM remains unchanged until a manual refresh explicitly supplies E. The separate recovery workflow’s pinned digest already differed from the baseline configuration, so this change does not newly disable that path. Pre-merge checks |
|
ELI5
Staging's director can only be deployed with the image that staging's c4 cell is declared on. This moves that declaration to the new image, E, so the director can run the event-loop freeze metric and its alert. Nothing rolls by itself.
What Changed
environments/staging.tfvars:staging-gce-c4.imagechanges from D (sha256:ac2ab357…) to E (sha256:94bc2b2d…). E is main2bdb55350d3, built by publish run 38125094372 and mirrored to staging by run 38125199997.relay-staging-c4-refresh-workflow.test.mjsfollows.Why
Deploy Relay Stagingrefuses anyexpected-image-digestother than c4's checked-in image. The director needs E foreventLoopDelayMsMax(#27405) and the stall alert (#27406).What it does not change. The live c4 VM stays on D until its own reviewed refresh workflow runs. Until then the checked-in value is ahead of the live cell, and step5-land, who owns c4, has been told.
Linked Issue
N/A (internal staging change).
Visual Proof
N/A: configuration only.
Testing
staging.tfvarspass.terraform fmt -checkpasses.AI Disclosure
N/A (internal contributor).
Agent skill upstream boundary
Checklist