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.
93 lines
3.4 KiB
Markdown
93 lines
3.4 KiB
Markdown
# 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
|