Wait for a new release to appear before writing the manifests - #55
Merged
Conversation
The releases API lags publication by seconds. Publish site runs on the release event, so the 0.9.5 run read a list that did not contain 0.9.5 yet, wrote a stable.json describing 0.9.4, and reported success - the site offered the previous version and the in-app update check agreed with it. The workflow now passes the published tag as -ExpectTag and the script waits for it, failing after ten attempts rather than writing a manifest it knows is stale. Nothing changes for push or manual runs, where the tag is empty. The same fetch also sorts on published_at. The API orders by created_at, which for a release carries the date of the commit its tag points at, so a pre-release built from a later commit already sorts above a release promoted from an earlier one - harmless with today's filters, wrong as soon as an older commit is promoted after a newer one.
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.
v0.9.5was published at 06:23:40. The Publish site run it triggered started at06:23:42 and succeeded — writing a
stable.jsonthat said 0.9.4.The releases API lags publication by seconds. The script takes the newest non-prerelease
from
/releases, got the previous one, and reported success. The site offered 0.9.4 andthe in-app update check agreed with it, which is the same user-visible damage as the tag
rule in #53 arriving by a different route.
dev.jsonwas correct only because the pre-release had eighteen minutes of lead timebefore its own run.
The fix
The workflow passes the tag being published as
-ExpectTag; the script polls until thattag appears, and fails after ten attempts rather than writing a manifest it knows is
stale. A loud failure is recoverable; a quiet wrong answer is what cost us a release.
The tag is empty for push and manual runs, so those paths are unchanged.
A latent bug found alongside it
The same fetch now sorts on
published_at. The API orders bycreated_at, which for arelease carries the date of the commit its tag points at — not when it was published. It is
already observable:
v0.9.4-dev.3244(created 20:32) sorts abovev0.9.4(created 19:43).Today's filters hide it, since the channels are separated before anything is picked. It
stops being hidden the first time an older commit is promoted after a newer one has already
been released.
Verified
Ran the script three ways against the live API: with
-ExpectTag v0.9.5(found, proceeds),with an empty tag (unchanged behaviour), and confirmed both manifests select correctly with
the new sort. The site has already been redeployed manually, so
whiteboard.sqlbi.com/stable.jsonnow reports 0.9.5.