mirror of
https://github.com/f-eld-ch/sitrep.git
synced 2026-08-31 07:08:29 +02:00
a90eb03c67
* feat(server): stamp the build identity and serve it on /version
main.go declared
// Version is the version of the application, set at build time.
var version = "dev"
but nothing set it: there was no .ko.yaml and no -ldflags anywhere, and the
Ko Build step exported a `Version` env that nothing read. The variable is
not dead — otel.go passes it to semconv.ServiceVersion — so every trace
and metric in production reported service.version="dev".
Adds .ko.yaml to inject it at link time, plus a `sha` alongside. The
version comes from docker/metadata-action so it matches the published
image tag; the commit comes from ko's own git context rather than the
workflow, so a local `ko build` stamps correctly too. The Ko Build step
now fails if the version is empty — stamping `-X main.version=` would ship
a binary reporting nothing at all, which is worse than the "dev" default
and invisible until someone reads a trace.
Exposes both on GET /version, unauthenticated like the health endpoints:
it reveals nothing the served asset filenames do not already. The UI is
embedded in this binary via ui.Assets, so this identifies the frontend
being served as much as the backend — which is what lets a client tell
whether the server has moved on from the page it is running.
No cache-control work needed: cacheControlMiddleWare already defaults to
no-store outside /assets/ and /map/. Verified against a running binary —
`-X main.version=v9.9.9 -X main.sha=deadbeefcafe` returns
{"sha":"deadbeefcafe","version":"v9.9.9"} with Cache-Control: no-store.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ui): show the new version's changelog in the update prompt
The update prompt offered a "view changelog" link and a version number
that both described the version the user was already running, not the
update being offered.
That is structural rather than a bug in the prompt: vite.config bakes
VITE_VERSION/VITE_SHA_VERSION in at build time, and the prompt is rendered
by the currently loaded bundle — so those constants are by definition the
old build's. A running page cannot learn a version released after it; it
has to ask the server.
It now fetches /version when needRefresh flips, and names that version and
its changelog. Keyed on needRefresh so it costs a request only when an
update actually exists. Falls back to the running version whenever the
lookup returns null, so the prompt still works offline and in a dev server
without the proxy — a prompt that cannot render is worse than one naming
the wrong version, since it is the only way to apply the update.
Collects the version concerns in utils/version.ts, which also fixes a
stale repo slug: the changelog URL was hard-coded as the pre-rename
RedGecko/sitrep in two components, working only because GitHub redirects
renamed repositories. Having it in two places is why it went stale.
Navbar deliberately keeps the pinned SHA — that element labels the version
the user is on, so the running build's changelog is the correct target
there. It only picks up the corrected slug.
The request URL derives from BASE_URL rather than assuming the site root,
the same mistake that made the sprite atlases 404 from a nested route, and
passes cache: "no-store" — a heuristically cached response would report
the version this page was served with, which is the bug being fixed.
Both are asserted, along with every failure path resolving to null rather
than throwing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ci): version builds with git describe, not the image tag
The stamped version came from docker/metadata-action's computed image tag.
That only produces a real version for tagged releases: the default branch
yields the literal "develop", main yields "stable", and a pull request
yields "pr-N". Since most deploys are not tagged, most backends would have
reported a branch name as their version — on /version, and in every trace
via semconv.ServiceVersion.
Worse, it disagreed with the frontend. The UI baked in git.tag(false), the
nearest tag, so a develop deployment would show "v26.8.0" in the navbar
and "develop" in the update prompt — two different version strings in the
same app, for the same build.
Both now use `git describe --tags --always`, which anchors every build to
the last release and counts from it. Verified byte-identical across the
two: the built bundle and a binary stamped the same way both report
v26.8.0-64-g136b9bf0. Tagged releases are unchanged, still v26.8.0.
Nothing was lost by dropping the metadata-action value: the published
image tags come from image_tags_labels, not from this, so the
correspondence it appeared to provide was never real.
Also adds fetch-depth: 0 to the docker workflow checkout. `git describe`
needs the tags and enough history to count commits since the last one, and
the default shallow fetch has neither — with --always it would have
silently degraded to a bare SHA rather than failing.
The UI shells out rather than using git-rev-sync, which has no equivalent:
its tag() passes --abbrev=0 (nearest tag, no count) and its count() is
total commits, not commits since the tag. Falls back to the previous
behaviour when git or the tags are unavailable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
25 lines
1.1 KiB
YAML
25 lines
1.1 KiB
YAML
# ko build configuration.
|
|
#
|
|
# Exists to stamp the build identity into the binary. `main.go` declares
|
|
#
|
|
# var version = "dev"
|
|
# var sha = "dev"
|
|
#
|
|
# and without -ldflags those defaults ship to production — which is why every trace and
|
|
# metric reported service.version="dev" (see otel.go, semconv.ServiceVersion) and why the
|
|
# UI update prompt could not name the version it was offering.
|
|
#
|
|
# ko matches a builds entry by joining `dir` and `main` against the requested import path.
|
|
# The workflow runs `ko build --bare .`, so `main: .` is the entry that applies.
|
|
builds:
|
|
- id: sitrep
|
|
main: .
|
|
ldflags:
|
|
# `git describe` output, supplied by the workflow — the same string the UI bakes in,
|
|
# so the backend and the frontend never report different versions. The Ko Build step
|
|
# fails fast if it is empty, since an empty version is worse than "dev".
|
|
- -X main.version={{.Env.SITREP_VERSION}}
|
|
# Taken from ko's own git context rather than the workflow, so a local `ko build`
|
|
# stamps correctly too and there is one less thing to plumb.
|
|
- -X main.sha={{.Git.FullCommit}}
|