Files

T

adebisi-fa 35d895574f docs(openspec): archive fpagent-install-upgrade and sync specs

Documents release pinning (--tag), the pinned-tag metadata route,
installed-version tracking with upgrade reporting, and restart of a
managed running service on upgrade; syncs the four requirements into the
fpagent-installer main spec.

2026-10-02 11:41:50 +01:00

1.7 KiB

Raw Blame History

Proposal: fpagent-install-upgrade

Why

The installer always took the newest release and left any running fpagent daemon on the old binary, so there was no way to hold a known-good version and an "upgrade" did not take effect until a reboot. Operators need a controlled version and a rerun that actually upgrades.

What Changes

The installer accepts --tag TAG to install a specific release instead of latest, and the app proxies that tag's metadata through a same-origin route.
The installed version is the git hash carried in the bundle's asset name. The installer passes it to the bundle installer, which records it beside the binary and reports upgrading <old> -> <new> on the next run.
When the installer manages the systemd service and the service was already running, an upgrade restarts it so the new binary takes effect. The version stamp is removed on uninstall.

Capabilities

New Capabilities

(none)

Modified Capabilities

fpagent-installer: adds release pinning, a pinned-tag metadata endpoint, installed-version tracking with upgrade reporting, and restart of a managed service on upgrade.

Impact

tools/server.js: /fpagent/releases/tags/:tag route (shares the release metadata handler with /fpagent/releases/latest).
tools/public/fpagent/install.sh: --tag, version parse from the asset name, and handoff of the version to the bundle installer.
fingerprint-agent deploy/install.sh and deploy/bundle.sh: read/stamp the version and restart an already-running service; bundle.sh ships VERSION.
Depends on the fingerprint-agent bundle naming, which already embeds the git hash (fpagent-<hash>-<platform>.tar.gz).

1.7 KiB Raw Blame History