Skip to content

pages.yml: retry stable release asset download instead of failing hard - #21

Merged
d3mocide merged 1 commit into
mainfrom
claude/github-actions-bot-failures-zjcccd
Sep 4, 2026
Merged

d3mocide merged 1 commit into
mainfrom
claude/github-actions-bot-failures-zjcccd

Conversation

@d3mocide

@d3mocide d3mocide commented Sep 4, 2026

Copy link
Copy Markdown
Owner

Summary

The two red "Deploy web flasher" runs (#20, #21) both failed at the same
step: gh release download "v1.0.7" ... no assets to download.

Cross-checking against the release object explains why: v1.0.7 went
draft → published at 19:41:54, but release.yml's build job didn't
finish uploading its four .bin assets until 19:43:50–51 — about two
minutes later. release.yml always creates the release as a draft on a
tag push; here the draft existed (empty) before the build even started,
and was manually published from the GitHub UI while the build was still
running. pages.yml's release: released trigger fired the instant it
was published, well before any assets existed to download.

pages.yml's own header comment claimed this ordering was safe ("by the
time this fires, release.yml's own job has long since finished, so its
assets are already attached") — that assumption doesn't hold once a
draft can be published independently of the build finishing.

Changes

  • .github/workflows/pages.yml: "Download stable release assets" now
    retries up to 6 times, 20s apart (~2 minutes total, matching how long
    the real v1.0.7 build took) instead of failing on the first empty
    response.
  • Corrected the stale "safe" claim in the workflow's header comment, and
    cited the actual failing run IDs.
  • CHANGELOG.md: terse entry for the fix.

dev-latest's download is untouched — its ordering guarantee (Build
uploads its own assets inside its own job, before the job completes)
held in both failing runs; only the manually-published stable-release
path was affected.

Test plan

  • python3 -c "import yaml; yaml.safe_load(open('.github/workflows/pages.yml'))" — YAML parses
  • Next tag/release publish exercises the retry path for real (or a manual workflow_dispatch run of Deploy web flasher against a draft published early)

🤖 Generated with Claude Code

https://claude.ai/code/session_01YR639KWW77CszwJYKjmNa2


Generated by Claude Code

runs 33912509081/33912608422 (v1.0.7, 2026-09-04) both failed at
"gh release download v1.0.7 ... no assets to download". Cross-checked
against the release object: v1.0.7 was published (draft -> non-draft)
at 19:41:54, but release.yml's build job didn't finish uploading its
four .bin assets until 19:43:50-51 -- about 2 minutes later. The
`release: released` trigger fired as soon as the draft was manually
published, well before the still-running build/upload job attached
anything.

The pages.yml header comment claimed this was safe ("release.yml's own
job has long since finished, so its assets are already attached") --
that assumption doesn't hold when a maintainer publishes an
already-created-but-still-empty draft before the CI build finishes.
Rather than rely on that timing, the stable-assets download step now
retries up to 6 times over 2 minutes before failing, matching how long
the real build took. dev-latest's download is unaffected: its ordering
guarantee (asset upload happens inside Build's own job, before the job
completes) held in both failing runs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR639KWW77CszwJYKjmNa2
@d3mocide
d3mocide marked this pull request as ready for review September 4, 2026 19:53
@d3mocide
d3mocide merged commit 3e31daa into main Sep 4, 2026
1 check passed
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