Show the build in a footer, linked to its release or commit

The version moves from the header to a "Powered by Jarl" footer. A build
of a release tag (HEAD tagged v<VERSION>, no tracked changes; the release
workflow sets RELEASE_TAG) shows and links the release; any other build
shows and links its commit, marked -modified with uncommitted changes.
jarld version, jarl --version, /status and /auth/whoami report the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
abrown38andClaude Opus 5.5 committed 2026-10-09 14:48:24 +00:00
1 parent b05711b13e
commit db9ebb14dd
14 files changed
+176 -14

No files matched your search

+16
View File
@@ -202,6 +202,22 @@ component `main` ([install.md](install.md#from-the-package-registry)). A
version with a hyphen (`1.0.0-rc.1`) becomes a pre-release; its packages
get version `1.0.0~rc.1`, which apt sorts before `1.0.0`.
### Which version a build reports
The footer of the web UI, `jarld version` and `jarl --version` say what a
binary was built from, linking to it on Gitea:
* **A release**: `make` run on the commit tagged `v<VERSION>` with no
tracked file changed. The Makefile then sets `RELEASE_TAG`, and the
footer reads "Powered by Jarl v0.2.0", linking to the release. The
release workflow sets `RELEASE_TAG` itself.
* **Any other build**: the commit, which Go records from git: "Powered by
Jarl 1a2b3c4d5e6f", linking to the commit. With uncommitted changes it
is marked `-modified`. The version commands print `0.2.0 (1a2b3c4d5e6f)`.
* **No git** (a build from a source tarball): just `VERSION`.
`RELEASE_TAG=v0.2.0 make` forces the first case.
Pushing the same tag again (`git tag -f`, `git push -f`) re-runs it, and
the script replaces the attachments and packages, so a failed release can
simply be retried.