adebisi-fa
35d895574f
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.
3.4 KiB
Spec Delta
ADDED Requirements
Requirement: Pinned release selection
The installer SHALL accept a release tag and install that release instead of the latest. Without a tag it SHALL install the latest release.
Scenario: A pinned release is installed
- WHEN the installer is invoked with a release tag
- THEN it fetches that tag's metadata and installs its bundle
Scenario: Default is the latest release
- WHEN the installer is invoked without a release tag
- THEN it installs the latest release
Scenario: Unknown pinned release
- WHEN the pinned tag does not exist
- THEN the installer exits with a failure message and installs nothing
Requirement: Pinned release metadata endpoint
The app SHALL expose a same-origin endpoint that returns a specific release's tag and asset names as same-origin URLs, with the same authentication, filtering and non-disclosure guarantees as the latest-release endpoint. It SHALL reject a tag that is not a valid release tag without contacting the forge.
Scenario: Tagged release is returned
- WHEN a client requests the metadata for an existing tag
- THEN the response carries that release's tag and its assets as same-origin URLs
Scenario: Invalid tag is rejected
- WHEN a client requests metadata for a tag that is not a valid release tag
- THEN the app rejects the request without contacting the forge
Requirement: Installed version is tracked and upgrades are reported
The installer SHALL treat the git hash in the bundle's asset name as the version. It SHALL hand that version to the bundle installer, which SHALL record it beside the installed binary and SHALL report an upgrade with the previous and new versions on the next run. Uninstalling SHALL remove the recorded version.
Scenario: Version is derived from the asset name
- WHEN the installer selects a bundle named
fpagent-<hash>-<platform>.tar.gz - THEN it uses
<hash>as the version
Scenario: Upgrade is reported
- WHEN the recorded version differs from the version being installed
- THEN the bundle installer reports the change from the old to the new version
Scenario: First install records the version
- WHEN no version has been recorded yet
- THEN the bundle installer records the new version and reports no upgrade
Scenario: Uninstall removes the recorded version
- WHEN the installer is asked to uninstall
- THEN the recorded version is removed
Requirement: A managed running service is restarted on upgrade
When the installer is asked to manage the systemd service and a service is already running, the installer SHALL restart it after installing the new binary so the new binary takes effect. A fresh install SHALL NOT perform a redundant restart, and the installer SHALL NOT restart the service when service management is not requested.
Scenario: Upgrade restarts the running service
- WHEN the running service is managed and a new binary is installed
- THEN the service is restarted on the new binary
Scenario: Fresh install starts the service
- WHEN the service is not running and service management is requested
- THEN the service is started and no separate restart is performed
Scenario: Service management not requested
- WHEN service management is not requested
- THEN the installer does not restart the service