Skip to content

ci: stop cancelled Ring 1 runs from failing the Fly deploy - #4784

Merged
georgi merged 1 commit into
mainfrom
claude/fly-deploy-issue-5xls1n
Aug 8, 2026
Merged

ci: stop cancelled Ring 1 runs from failing the Fly deploy#4784
georgi merged 1 commit into
mainfrom
claude/fly-deploy-issue-5xls1n

Conversation

@georgi

@georgi georgi commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

What broke

Run 31256065058 failed on its first poll:

attempt 1/60: docker.yml=success user-journeys.yml=cancelled
::error::user-journeys.yml (reliability-ring1) concluded 'cancelled' for 97f053e…; not deploying.

user-journeys.yml carried cancel-in-progress: true on a group keyed by ref, so two merges landing on main within three minutes (97f053e at 11:47, 8cdf606 at 11:50) cancelled the earlier commit's reliability-ring1 run. fly-deploy.yml's gate reads a per-commit conclusion and treats cancelled as a hard failure — so a commit that was merely superseded produced a red deploy. The same pattern shows up repeatedly in the run history (four consecutive cancellations on 2026-08-07).

Changes

  • user-journeys.yml — don't cancel superseded runs on main, using the same expression docker.yml already uses. Every main commit's Ring 1 now reaches a conclusion of its own, which is exactly what the gate polls for. PR branches and tags still cancel.
  • fly-deploy.yml — when an upstream is red or cancelled for a commit main has already moved past, skip the deploy instead of failing it. The gate emits a deploy output that deploy's if requires, so a superseded commit ends green-and-skipped rather than red, and the newer commit's own run does the releasing.
  • Fold timed_out into the terminal conclusions the gate reacts to, instead of polling on until the 65-minute job timeout.
  • .github/workflows/README.md — record why Ring 1 doesn't cancel on main, since that's the non-obvious coupling.

Verification

Both workflow files parse. The gate script was extracted and exercised against a stubbed gh across four cases:

docker journeys commit is tip of main result
success success yes exit 0, deploy=true
success cancelled no exit 0, deploy=false, notice
success cancelled yes exit 1, error (unchanged)
failure success yes exit 1, error (unchanged)

A genuinely failing Ring 1 on the tip of main still blocks the deploy — only the superseded case changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LGkCEj3kPc4QMCxBPGo95p


Generated by Claude Code

Two merges landing on main within a few minutes cancelled the earlier
commit's User Journeys run (cancel-in-progress keyed on the ref), and
fly-deploy's gate treats a cancelled reliability-ring1 as a hard failure —
so a superseded commit produced a red deploy.

- user-journeys.yml: keep superseded runs on main alive, matching
  docker.yml's expression. Every main commit's Ring 1 now reaches a
  conclusion of its own, which is what the gate reads.
- fly-deploy.yml: when an upstream is red or cancelled for a commit main
  has already moved past, skip the deploy (deploy=false output) instead of
  failing. The newer commit's own run does the releasing.

Also fold timed_out into the terminal conclusions the gate reacts to,
rather than polling until the 65-minute job timeout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LGkCEj3kPc4QMCxBPGo95p
@georgi
georgi enabled auto-merge (squash) August 8, 2026 12:10
@georgi
georgi merged commit fec84af into main Aug 8, 2026
22 checks passed
@georgi
georgi deleted the claude/fly-deploy-issue-5xls1n branch August 8, 2026 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants