Admin version tab: show running version + "check for updates" against the public repo (post-launch) #180

New issue

Closed

opened 2026-08-10 00:50:41 +00:00 by Cordy · 1 comment

Cordy commented

2026-08-10 00:50:41 +00:00

Owner

Filed in v0.8 deliberately: the check needs the public GitHub mirror (#27) to exist, and Nikola's note already says to test it in the going-public milestone.

Design position to ratify when we get here:

Version display: trivial — /api/v1/admin/info already carries version; the admin panel shows it today only implicitly. A proper card: running version, release date, link to CHANGELOG.
Check for updates: GET https://api.github.com/repos/<mirror>/releases/latest compared against the running version. Strictly opt-in and click-triggered — Cairn's no-phone-home posture is a selling point (the license check-in is the one documented exception); a background update pinger would betray it. Air-gapped instances simply see "check" fail gracefully.
An "update" button is almost certainly a non-goal. Cairn doesn't own its own lifecycle: containers are updated by bumping the image tag (Helm/compose/GitOps), bare-metal by replacing one binary. A self-updating server would fight every one of those deployment models and add a privileged writable-binary requirement we don't want. The honest feature is: detect, notify, link to the upgrade section of docs/handbook/deployment.md (which documents the CHANGELOG-first upgrade rule). If beta feedback demands more, the ceiling is a copy-pasteable per-deployment command, never in-process self-replacement.

Dogfood note (Nikola): how does an operator update their Cairn instance? Wanted: a version tab in the admin panel showing the current version, a "check version" button reaching out to the GitHub repo, and thoughts on an "update" button. **Filed in v0.8 deliberately**: the check needs the public GitHub mirror (#27) to exist, and Nikola's note already says to test it in the going-public milestone. **Design position to ratify when we get here:** - **Version display**: trivial — `/api/v1/admin/info` already carries `version`; the admin panel shows it today only implicitly. A proper card: running version, release date, link to CHANGELOG. - **Check for updates**: `GET https://api.github.com/repos/<mirror>/releases/latest` compared against the running version. Strictly opt-in and click-triggered — Cairn's no-phone-home posture is a selling point (the license check-in is the one documented exception); a background update pinger would betray it. Air-gapped instances simply see "check" fail gracefully. - **An "update" *button* is almost certainly a non-goal.** Cairn doesn't own its own lifecycle: containers are updated by bumping the image tag (Helm/compose/GitOps), bare-metal by replacing one binary. A self-updating server would fight every one of those deployment models and add a privileged writable-binary requirement we don't want. The honest feature is: detect, notify, link to the upgrade section of `docs/handbook/deployment.md` (which documents the CHANGELOG-first upgrade rule). If beta feedback demands more, the ceiling is a copy-pasteable per-deployment command, never in-process self-replacement.

Cordy added this to the v0.8 — Public launch milestone

2026-08-10 00:50:41 +00:00

Cordy referenced this issue from a commit

2026-08-12 03:04:59 +00:00

ci: v0.6.14 edit script (#180 version + update check)

Cordy referenced this issue from a commit

2026-08-12 03:05:32 +00:00

ci: v0.6.14 ship workflow (#180)

forgejo-actions referenced this issue from a commit

2026-08-12 03:06:14 +00:00

v0.6.14: admin version display + configurable update check (#180)

Cordy referenced this issue

2026-08-12 03:07:54 +00:00

v0.6.14: admin version display + configurable update check (#180) #201

Cordy referenced this issue from a commit

2026-08-12 03:09:17 +00:00

v0.6.14: admin version display + configurable update check (#180) (#201)

Cordy commented

2026-08-12 03:52:42 +00:00

Author

Owner

Done in v0.6.14 (PR #201), live on the dogfood: the admin Settings card shows the running version and, with an updates config block, checks a Forgejo /tags feed and reports up-to-date / newer-available (notify-only, semver-compared, deployment-appropriate how-to hint + release link). Verified working (Updates: Up to date).

The remaining piece — swapping tagsUrl from the Forgejo repo to the public GitHub mirror — is gated on the mirror going public (#27), so it's being tracked as its own v0.8 launch task rather than left open here. Closing.

Done in **v0.6.14** (PR #201), live on the dogfood: the admin Settings card shows the running version and, with an `updates` config block, checks a Forgejo `/tags` feed and reports up-to-date / newer-available (notify-only, semver-compared, deployment-appropriate how-to hint + release link). Verified working (`Updates: Up to date`). The remaining piece — swapping `tagsUrl` from the Forgejo repo to the public GitHub mirror — is gated on the mirror going public (#27), so it's being tracked as its own v0.8 launch task rather than left open here. Closing.

Cordy closed this issue

2026-08-12 03:52:48 +00:00

Cordy referenced this issue

2026-08-12 03:53:05 +00:00

Switch update-check tagsUrl to the public GitHub mirror #202