Skip to content

fix(ci): serialise docs deploys so release tags stop racing main#46

Open
CSSFrancis wants to merge 1 commit into
mainfrom
fix/docs-deploy-race
Open

fix(ci): serialise docs deploys so release tags stop racing main#46
CSSFrancis wants to merge 1 commit into
mainfrom
fix/docs-deploy-race

Conversation

@CSSFrancis

Copy link
Copy Markdown
Owner

The failure

The Docs run for tag v0.5.0 failed at the deploy step:

! [remote rejected] gh-pages -> gh-pages
  (cannot lock ref 'refs/heads/gh-pages': is at 38726cd but expected 0f190b2)

Build docs succeeded — only the push lost.

Why the existing guard didn't catch it

# Only one docs deployment should run at a time to avoid race conditions on
# the gh-pages branch.
concurrency:
  group: docs-${{ github.ref }}

A push to main and a push to its v* tag are different refs, so they go
into different concurrency groups and run concurrently. Both push to
gh-pages; the second is rejected. The guard never applied to the case its own
comment describes.

Why it matters more than a red X

prepare_release adds the new version to switcher.json regardless, so a lost
deploy leaves the switcher advertising a directory that doesn't exist. On
gh-pages today both v0.4.2 and v0.5.0 are missing while the switcher
offers them — those entries 404.

The fix

Split the two concerns:

  • workflow level keeps a per-ref group (docs-build-${{ github.ref }}) so a
    new push still supersedes an in-flight build of the same ref — PR iterations
    keep cancelling as before.
  • the deploy job takes a ref-independent group (docs-deploy) with
    cancel-in-progress: false, so deploys queue. Cancelling would drop a
    version directory just as surely as the race did.

Backfill

Not included here. Re-running the two Docs runs publishes the missing
directories — keep_files: true makes deploys additive, so nothing is
overwritten. I've already re-run the v0.5.0 one.

🤖 Generated with Claude Code

https://claude.ai/code/session_012TTbBeDrPJBTpruuszC3mD

The concurrency guard was keyed on github.ref with the comment "Only one
docs deployment should run at a time to avoid race conditions on the
gh-pages branch". A push to main and a push to its v* tag are different
refs, so they landed in different groups and ran concurrently — the guard
never applied to the case it was written for.

Both runs push to gh-pages. The second lost:

  ! [remote rejected] gh-pages -> gh-pages (cannot lock ref
    'refs/heads/gh-pages': is at 38726cd but expected 0f190b2)

The build itself succeeded, so the failure looks cosmetic in the Actions
tab, but the versioned directory never gets published while
prepare_release has already added the version to switcher.json — so the
switcher offers a 404. v0.4.2 and v0.5.0 are both missing from gh-pages
for this reason.

Split the grouping: the workflow keeps a per-ref group so a new push
still supersedes an in-flight build of the same ref (PR iterations), and
the deploy job takes a ref-independent "docs-deploy" group with
cancel-in-progress: false so deploys queue. Cancelling would drop a
version directory just as surely as the race did.

Does not backfill the two missing directories — re-running those Docs
runs publishes them, since keep_files: true makes deploys additive.

Assisted-by: Claude Opus 5 (1M context)
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.32%. Comparing base (1ea6bac) to head (5ee43d2).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #46   +/-   ##
=======================================
  Coverage   90.32%   90.32%           
=======================================
  Files          39       39           
  Lines        4185     4185           
=======================================
  Hits         3780     3780           
  Misses        405      405           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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