Dedupe the preview-build predicate, fix two comment inaccuracies
Secret Scan / scan (push) Successful in 24s
Build App (Preview) / compute-version (pull_request) Successful in 6s
Secret Scan / scan (pull_request) Successful in 6s
Build App (Preview) / create-release (pull_request) Successful in 1s
Build App (Preview) / build-macos (pull_request) Successful in 2m39s
Build App (Preview) / build-windows (pull_request) Successful in 4m44s
Build App (Preview) / build-linux (pull_request) Successful in 6m17s
Build App (Preview) / prune-previews (pull_request) Successful in 1s

Final review pass gave this a clean bill of health overall but named
three small things:

- get_app_version() and check_for_updates() each read
  option_env!("TRIPLE_C_BUILD_SUFFIX") independently with slightly
  different idioms — if one were ever edited alone, the About panel and
  the update check could silently disagree about whether this is a
  preview build. Extracted preview_build_suffix() as the single place
  that reads and classifies it.
- pick_update's doc comment described the unparseable-tag case as a
  `-preview.<sha>` suffix; the actual tag build-app-preview.yml creates is
  `preview-<sha>` (no version, no dot) — already correct in the
  neighboring GitHubRelease::prerelease comment, just not here.
- That same prerelease comment claimed defence against a preview release
  leaking through backfill-releases.yml, but a preview's tag already fails
  semver parsing on its own — this field's actual job is the case parsing
  can't catch: a normally-tagged release someone flags prerelease on
  Gitea (a hotfix candidate, an RC) that a backfill would otherwise mirror
  as-is.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGjXq6fqtAFHdbhk4f3PfZ
This commit is contained in:
2026-08-27 10:34:56 -07:00
co-authored by Claude Sonnet 5
parent 945883bb9d
commit 049232099b
2 changed files with 25 additions and 13 deletions
+6 -5
View File
@@ -36,11 +36,12 @@ pub struct GitHubRelease {
///
/// `build-app.yml`'s own mirror never publishes a prerelease, but
/// `.gitea/workflows/backfill-releases.yml` forwards every Gitea release
/// unfiltered, `prerelease` included — so if it were ever dispatched
/// while a preview release existed, this field is what stops
/// `check_for_updates` from offering it (the `preview-<sha>` tag shape
/// already fails semver parsing independently, but this is real
/// defence-in-depth, not a no-op).
/// unfiltered, `prerelease` included. A preview release's `preview-<sha>`
/// tag already fails semver parsing on its own, so this field is not what
/// stops *that* case — it is what stops the case tag-parsing can't catch:
/// a normally-tagged release (`v0.4.13`) that someone marks as a
/// prerelease on Gitea (a hotfix candidate, an RC) and a backfill then
/// mirrors as-is. Real defence for that case, not a no-op.
#[serde(default)]
pub prerelease: bool,
}