Repository navigation
[Sync to prerelease] Fix older publishes overwriting newer deploys - #2296
Merged
Merged
Conversation
* Serialize publishes per deployed site publish.yml grouped its concurrency by the calling workflow and ref, so deploys of the same site from different workflows (a push, update-downloads, the axe report, the prerelease sync) ran in separate groups and an older build finishing last could overwrite a newer deploy. The group is now keyed on the deployed site, whichever workflow calls publish.yml. The site is picked the way the deploy steps pick it: an explicit prerelease input wins over github.ref. A called workflow inherits the caller's ref, so falling back to the ref whenever the input was false would put the quarto.org publish of an Axe Report dispatched from prerelease in the prerelease group, cancelling its sibling. * Publish the branch tip so a cancelling run never deploys older content With one concurrency group per site, the run that queues last cancels the one in progress. update-downloads and axe-scan passed the SHA they had just pushed, so a publish queued a few seconds late could cancel a run for a newer commit and deploy the older SHA. Push-triggered runs had the same exposure through the default checkout of github.sha. Every caller now passes a branch name, and the checkout falls back to github.ref instead of github.sha, so each run builds the branch tip as it stands when the job starts. The commit-hash job outputs that only fed the pinned refs are removed. * Keep publishes that deploy nothing out of the main group Dispatching Quarto Publish from a branch other than main or prerelease deploys neither site, but its run fell into the main group and cancelled any quarto.org publish in progress, leaving those changes unpublished. The previous group included the ref, so such a run was isolated. It now gets a group named after its ref. * Render with the profile of the site being deployed A called workflow inherits the caller's ref and event. Dispatching Axe Report from prerelease called publish.yml for quarto.org with prerelease: false, but github.ref was refs/heads/prerelease, so the render used the prerelease-docs profile and quarto.org was deployed with prerelease branding and site URLs. The profile condition now carries the same guard as the prerelease deploy step, so an explicit prerelease: false always renders the release profile. (cherry picked from commit 6965812)
1 of 3 tasks
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.
Description
Sync of #2294 to
prerelease.Original PR
Fix older publishes overwriting newer deploys
Deploys of the same site from different workflows do not wait for each other.
publish.ymlgrouped its concurrency by calling workflow and ref, so a publish from a push tomain, fromupdate-downloads.ymland from the axe report each ran in their own group, and an older build finishing last could overwrite a newer deploy.This becomes more frequent with #2293, where sync PRs are merged right away and publish
prereleasethemselves.Fix
There is now one concurrency group per deployed site, quarto.org and prerelease.quarto.org, whichever workflow calls
publish.yml. The site is picked the same way the deploy steps pick it, so a caller passingprerelease: falsefrom theprereleasebranch (the axe report dispatched there) still lands in the quarto.org group. A dispatch ofpublish.ymlfrom any other branch deploys neither site, so it gets its own group and never cancels a deploy.In a shared group, the run that queues last cancels the one in progress. Every publish now checks out the branch tip when the job starts instead of a fixed commit, so the run that wins includes every earlier change.
update-downloads.ymlandaxe-scan.ymlpass the branch name instead of the commit they just pushed, and push-triggered runs check outgithub.refinstead ofgithub.sha.The render profile had the same problem, already on
main. A called workflow inherits the caller's ref, so the axe report dispatched fromprereleaserendered its quarto.org publish with theprerelease-docsprofile, and quarto.org was deployed with prerelease branding and site URLs. The profile is now picked with the same guard as the prerelease deploy step, soprerelease: falsealways renders the release profile.Test Plan
zizmorandactionlinton the workflows: no new findingsmainpublishes quarto.org from the branch tipUpdate Downloadsrun with changes publishes both sites