Only offer an update once the release has been promoted - #429
Merged
Conversation
Two halves of the same bug. The upload steps passed no `prerelease` to softprops/action-gh-release, which defaults it to false and writes it back. Attaching assets therefore promoted the release it was attaching them to. v0.13.0 and v0.14.0 were both published as pre-releases and both ended up marked as the latest release within the hour, which also fired `released` and pushed :latest to GHCR. Each workflow now carries the release's own flag. The updater took the newest non-draft release, pre-releases included. That was deliberate when it was written, because /releases/latest hides pre-releases and every release was one, so tracking stable meant nobody would ever be notified. With the flag preserved, a pre-release is now genuinely a pre-release, and offering it would push unverified builds to everyone. It now takes the newest release that is neither draft nor pre-release, so a release reaches users only once it has been promoted. The e2e stub grew an unpromoted pre-release ahead of the stable one, and the spec pins which of the two the card names.
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.
Two halves of the same bug, found while publishing v0.14.1.
The release flag was being clobbered
None of the three release workflows passed
prereleasetosoftprops/action-gh-release. The action defaults it tofalseand writes it back, so each platform's upload step silently promoted the release it was attaching assets to.Both were published as pre-releases and both ended up marked as the latest release within the hour. That also fires the
releasedevent, whichdocker-publish.ymlhandles by pushing:latestto GHCR, so a pre-release became the:latestimage. Every release workflow now carriesprerelease: ${{ github.event.release.prerelease }}.The updater offered pre-releases
checkForUpdatetook the newest non-draft release, pre-releases included. That was deliberate when written:/releases/latestexcludes pre-releases, and since every StemDeck release was one, tracking stable would have meant nobody was ever notified.With the flag now preserved, a pre-release is genuinely a pre-release, and offering it would push unverified builds to every user. The check now takes the newest release that is neither a draft nor a pre-release.
The release flow this establishes: publish as a pre-release, which triggers the builds, verify it, then promote it ("Set as the latest release"). Only at that point are users offered the update.
Testing
v9.9.9rather thanv9.9.10, so the filter is pinned rather than incidental.if: github.event_name == 'release', so the release context is always present where the expression is evaluated.Note
Only
catalog.jsconsumes the releases API. The Rust side receives asset URLs from the frontend (AppUpdateQuery), so this filter is the single decision point and the two halves cannot disagree.