Three things, all needed before the update loop can be tested. The public signing key is committed. Verified before trusting it: algorithm `Ed`, key ID 90E96FEA2F6D9B6A matching its own comment, 32-byte Ed25519 key. Dev builds now carry a version that RISES. Every build took its version from Cargo.toml, so each one was 0.1.0 — an installed 0.1.0 would read a manifest advertising 0.1.0, conclude it was current, and never update. The rolling channel would have looked broken while working exactly as written. Dev builds are now 0.1.<ci-run-number>, from one helper shared by both bundle jobs and the manifest writer, because three separate derivations of "what version is this" is three chances for the binary and the manifest to disagree. Plain semver, not a `-dev.N` prerelease: prerelease versions sort BELOW the release they qualify, so a tagged build would never update to a newer dev one, and Windows installer metadata wants a numeric X.Y.Z regardless. Bumping the minor still beats any dev build on the old line — 0.2.0 > 0.1.2932. The Windows job also gets the signing environment it was missing, so its NSIS installer is signed too. Without that the manifest would have had a Linux entry and nothing for the platform actually being tested. docker-compose.yml is now the production stack, per request: it pulls the published image instead of building, keeps Postgres OFF the host network, sets restart policies, health checks and log rotation, and refuses to start without a POSTGRES_PASSWORD rather than shipping a known one. Volume names are deliberately unchanged so an existing deployment upgrades in place instead of silently coming up against an empty database. Development keeps its own clearly-named file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi
33 lines
1.6 KiB
Bash
Executable File
33 lines
1.6 KiB
Bash
Executable File
#!/usr/bin/env sh
|
|
#
|
|
# Echo the version this build should carry. One definition, used in three places
|
|
# (both bundle jobs and the manifest writer) — if they ever disagreed, the app would
|
|
# compare its own version against a manifest describing a different build, and the
|
|
# updater would either offer nothing or loop forever offering the same thing.
|
|
#
|
|
# WHY DEV BUILDS NEED THEIR OWN VERSION AT ALL:
|
|
# an updater decides by comparing semver. Every dev build carries the version in
|
|
# Cargo.toml, so without this they'd all be `0.1.0` — an installed build would see a
|
|
# manifest advertising the version it already has, conclude it was current, and never
|
|
# update. The rolling channel needs a number that actually rises.
|
|
#
|
|
# The CI run number is that number: monotonic, already unique per build, and it needs
|
|
# no state carried between runs. `0.1.0` + run 2932 becomes `0.1.2932`.
|
|
#
|
|
# Plain semver on purpose, NOT a `-dev.N` prerelease tag: prerelease versions sort
|
|
# BELOW the release they qualify (`0.1.0-dev.5` < `0.1.0`), so a tagged build would
|
|
# never update to a newer dev one, and Windows installer metadata wants a numeric
|
|
# X.Y.Z anyway. Bumping the minor in Cargo.toml still wins over any dev build on the
|
|
# old line, which is the ordering you want: 0.2.0 > 0.1.2932.
|
|
set -eu
|
|
|
|
CARGO_TOML="$(dirname "$0")/../src-tauri/Cargo.toml"
|
|
base="$(grep -m1 '^version' "$CARGO_TOML" | sed -E 's/.*"([^"]+)".*/\1/')"
|
|
|
|
# Dev builds only. Anything else (a v* tag, main) ships the version as written.
|
|
if [ "${GITHUB_REF_NAME:-}" = "dev" ] && [ -n "${GITHUB_RUN_NUMBER:-}" ]; then
|
|
printf '%s.%s\n' "${base%.*}" "$GITHUB_RUN_NUMBER"
|
|
else
|
|
printf '%s\n' "$base"
|
|
fi
|