Conversation
Concurrent build-docs runs (different PRs, or a PR preview deploy racing a main/release deploy) all push into the same gh-pages branch. The existing concurrency group in ci.yml is scoped per-ref, so it does not prevent two different refs from deploying docs at the same time. When that happens, the losing push is non-fast-forward and the JamesIves/github-pages-deploy-action step fails; a re-run usually succeeds once the branch is free. Add a job-level concurrency group scoped to the shared deploy target (gh-pages) so these runs queue instead of racing, with cancel-in-progress: false to avoid canceling a run mid-push and leaving gh-pages partially updated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
Contributor
Author
|
Closing in favor of #2883, though this can be a backup if that doesn't work. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
build-docs.ymldeploy step intermittently fails, and re-running the workflow with no other changes usually makes it pass (e.g. https://github.com/NVIDIA/cuda-python/actions/runs/35119260160/job/104877138975, which failed on the Deploy or clean up doc preview step).That step pushes rendered docs into the shared
gh-pagesbranch viaJamesIves/github-pages-deploy-action, either as a PR preview (docs/pr-preview/pr-<N>/) or as themain/release deploy. The action fetchesgh-pages, commits on top, and pushes, with only a small built-in retry.The existing
concurrencygroup inci.ymlis scoped per-ref (${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}), so it only cancels/serializes runs for the same PR or branch. It does nothing to stop two different refs — e.g. two separate PRs, or a PR preview deploy racing amaindeploy — from running their docs-deploy jobs at the same time. When that happens, both jobs push against the same base commit ongh-pages; one wins, the other's push is non-fast-forward, the action's retry budget gets exhausted under contention, and the step fails. Re-running later succeeds once the branch is free, which matches the observed "flaky, but a re-run fixes it" pattern.Fix
Add a job-level
concurrencygroup on thebuildjob inbuild-docs.yml, scoped to the shared deploy target rather than the ref:Because the group key (
gh-pages-deploy) is the same for every run of this job regardless of which ref triggered it, GitHub Actions queues runs that reach this job instead of letting them execute concurrently — this serializes all pushes togh-pagesacross PRs,main, and releases.cancel-in-progress: falseis intentional: canceling a queued run mid-push could leavegh-pagespartially updated, so runs wait their turn rather than being killed.Test plan
build-docsrun completes and deploys its preview successfully.mainpushes / PR docs builds for the previously-observed non-fast-forward failure on the deploy step; it should no longer occur.