fix: report a blocked-but-deployed service instead of failing the deploy - #6
Conversation
data-discord cannot log its readiness line until Message Content Intent is enabled for the Data application, so the deploy job failed on a blocker that lives outside this repository. The deploy now accepts a running service whose log names that exact precondition, emits an Actions warning that names the fix, and still fails for any other reason the service never becomes ready.
|
This pull request modifies the deployment script to prevent deploy failures when a service is running but blocked by an external precondition. It introduces a
Reviewers, please start by examining |
|
This pull request modifies the deployment script to prevent deploy failures when a service is running but blocked by an external precondition. It introduces a
Reviewers, please start by examining |
1 participant
Why
Merging Data's Discord channel made the deploy job red:
data-discordcannot logready: data-discorduntil Message Content Intent is enabled for the Data application, so the readiness wait timed out on a precondition that does not live in this repository.A red deploy for an external toggle is a false alarm: it hides real deploy failures and trains everyone to ignore the job.
What
scripts/zo-deploy.tsgains--waiting-marker <text>. When the readiness deadline passes, a service that isRUNNING, on the new revision, and whose log names that exact marker is accepted — with an Actions::warning::naming the blocker:Anything else still fails the job, unchanged.
deploy.ymlpasses the marker only fordata-discord.Verification
npm run typecheckandnpm test(13 tests, including the fake-MCP deploy tests) pass.data-discord, observed the4014line, emitted the warning above, and exited 0.