509 lines
35 KiB
Gherkin
509 lines
35 KiB
Gherkin
Feature: Updates part 3: Restart, the privileged helper and rollback
|
|
|
|
As the owner of a RenewCMS site
|
|
I want one Restart button that installs the staged release, or just restarts the site, and puts the old version back if the new one does not come up
|
|
So that I can update from the browser while the app itself stays unprivileged and sandboxed
|
|
|
|
Background:
|
|
Given slices 1 to 3 of Updates ship in one release
|
|
And the app never gains privileges: the documented systemd unit keeps ProtectSystem=strict and only the data directory writable
|
|
And only the helper runs as root; it is the same binary, started as "renewcms apply-update" by a oneshot systemd service
|
|
And the data directory is the directory that holds DB_FILE; no new env var is added
|
|
And the files in the data directory are:
|
|
update-restart-request.json (marker, written by the app):
|
|
{"kind":"update"|"restart","tag" (update only),"requested_at" RFC3339 UTC,"requested_by" user_id};
|
|
update-result.json (written by the helper):
|
|
{"outcome":"running"|"succeeded"|"rolled_back"|"failed","kind","tag","from_version","started_at","finished_at"};
|
|
update-helper.json (status file, written by enable-browser-updates):
|
|
{"version":1,"service","binary","data_dir","installed_at"};
|
|
update-running.json (written by the server at every startup):
|
|
{"version","pid","started_at"}
|
|
And the marker is written atomically (temp file in the data directory, then rename) and deleted by the helper after reading it
|
|
And the technical reason of a failure goes to the log or journal only, never into a file the app serves or a response
|
|
And the domain package internal/domain/update (stdlib only) gains these interfaces, each faked in tests:
|
|
RestartRequestStore (write, read, delete the marker),
|
|
ResultStore (read, write and delete the result),
|
|
RunningInfoStore (the server writes update-running.json; the helper reads it),
|
|
HelperFilesystem (lstat, open with no-follow, read, create-exclusive, copy, rename, remove, chmod, make a fresh private
|
|
temp directory, all of them symlink-aware),
|
|
ServiceControl (restart and status of the systemd service),
|
|
HealthChecker (GET http://127.0.0.1:<port>/healthz, true on 200),
|
|
Clock
|
|
And the helper logic depends only on those interfaces and on update.SignatureVerifier from slice 2 with the embedded release.pub
|
|
And O_NOFOLLOW and lstat behaviour sit behind HelperFilesystem so the logic is tested on any OS; the real adapter is Linux-only
|
|
(build-tagged) and is covered by the manual systemd checklist
|
|
And RequestRestartUseCase and the extended GetUpdateStatusUseCase depend only on domain interfaces; handlers in
|
|
api/handlers/update receive them through NewHandler; only api/dependecyInjection.go builds the adapters
|
|
And POST /v1/system/update/restart is mounted in NewSystemRouter behind jwtauth.Verifier, jwtauth.Authenticator,
|
|
RequireCurrentToken, RequireVerifiedUser and RequireOwner; there is no limiter
|
|
And its optional JSON body is {"kind":"update"|"restart"}, bound to a request struct with
|
|
validate:"omitempty,oneof=update restart" and checked by validator.Validate.Struct; an empty body is allowed
|
|
And the checks on POST run in this order: no cookie or stale token (401), unverified (403), not owner (403),
|
|
malformed body or invalid kind (400), can_apply false (409), job downloading or verifying (409), a restart already pending
|
|
or running (409), kind that does not match the state (409), marker write error (500), then 202
|
|
And with no body the server picks by state: job "ready" gives kind "update", anything else kind "restart"
|
|
And the kind given must match: "update" needs a job "ready"; "restart" needs no job "ready"; otherwise 409 and nothing is written
|
|
And POST download and POST restart delete update-result.json before they start a new job or write a marker
|
|
And the 202 body is the status JSON with state "restarting" and started_at equal to the marker's requested_at (server clock)
|
|
And errors are plain text from http.Error and carry no path or technical detail
|
|
And GET /v1/system/update has no side effects; it keeps the 12 keys of slice 1 and gains exactly one key, "finished_at":
|
|
the result's finished_at (RFC3339 UTC) whenever a result file exists, otherwise null, whatever the state
|
|
And state is one of idle, downloading, verifying, ready, restarting, succeeded, failed, derived from the files by one rule:
|
|
marker present, or result "running" younger than 5 minutes: "restarting";
|
|
result "running" older than 5 minutes and no marker: "failed", error "install";
|
|
result "succeeded", kind "update", tag equal to the running version: "succeeded";
|
|
result "succeeded" for kind "restart", or kind "update" whose tag is no longer the running version: "idle";
|
|
result "rolled_back": "failed", error "rolled_back";
|
|
result "failed": "failed", error "install";
|
|
otherwise the slice 2 job state; a missing or corrupt result file counts as no result
|
|
And a result persists and is read the same on every GET until POST download or POST restart deletes it
|
|
And error is null, "download", "verification", "rolled_back" or "install"
|
|
And GET /healthz is unchanged: body "ok", no version header
|
|
And the server writes update-running.json at every startup, after the listener is bound and before it serves, atomically; a write error
|
|
is logged and is not fatal
|
|
And the helper judges a restart by two things: GET /healthz answers 200 AND update-running.json holds the expected version AND it is
|
|
NEW: its pid differs from the pid read before the restart, or its started_at is later than the instant the restart command
|
|
was issued; a stale file with the old pid or started_at never counts
|
|
And main gains a minimal dispatcher before the normal start: the subcommands enable-browser-updates, disable-browser-updates and
|
|
apply-update run their own code and never read .env, open the database or listen; "--version" and the normal start are unchanged
|
|
And the new subcommands never write a secret value or an env value into a unit file
|
|
|
|
Scenario: Request an update restart, happy path
|
|
Given the owner, can_apply true and a job "ready" for "v2.3.0-beta"
|
|
When the owner sends POST /v1/system/update/restart with no body, or with {"kind":"update"}
|
|
Then the status is 202 and the body is the status JSON with state "restarting"
|
|
And the marker holds kind "update", tag "v2.3.0-beta", requested_by the owner's user_id and requested_at
|
|
And update-result.json was deleted first
|
|
And the running binary, the staged files and the database are unchanged by the app
|
|
And GET reports state "restarting" for any verified user
|
|
|
|
Scenario: Request a plain restart
|
|
Given the owner, can_apply true and no job "ready"
|
|
When the owner sends POST /v1/system/update/restart with no body, or with {"kind":"restart"}
|
|
Then the status is 202, the marker holds kind "restart" and no tag, and GET reports state "restarting"
|
|
|
|
Scenario Outline: The kind must match the state
|
|
Given the owner, can_apply true and <state>
|
|
When the owner sends POST /v1/system/update/restart with {"kind":"<kind>"}
|
|
Then the status is 409, no marker is written, the result file and the job are untouched
|
|
|
|
Examples:
|
|
| state | kind |
|
|
| no job "ready" (idle) | update |
|
|
| a job "failed" | update |
|
|
| a job "ready" | restart |
|
|
|
|
Scenario: Restart site never installs an update another owner just made ready
|
|
Given owner A opened the Plain restart dialog while the job was idle
|
|
And owner B then made a job "ready"
|
|
When owner A confirms and the SPA sends {"kind":"restart"}
|
|
Then the status is 409, nothing is installed and the staged files are untouched
|
|
And the SPA reloads the card and shows "Ready to install"
|
|
|
|
Scenario Outline: A bad body is a 400
|
|
Given the owner and can_apply true
|
|
When the owner sends POST /v1/system/update/restart with <body>
|
|
Then the status is 400 with a plain text body and no marker is written
|
|
|
|
Examples:
|
|
| body |
|
|
| {"kind":"upgrade"} |
|
|
| {"kind":""} |
|
|
| {"kind":7} |
|
|
| {"kind":"update" |
|
|
| not json |
|
|
|
|
Scenario Outline: POST is guarded like the other system routes
|
|
When <caller> sends POST /v1/system/update/restart
|
|
Then the status is <status> and no marker is written and no result is deleted
|
|
|
|
Examples:
|
|
| caller | status | body |
|
|
| no jwt cookie | 401 | the existing 401 text |
|
|
| a stale token version | 401 | the existing 401 text |
|
|
| an unverified owner | 403 | the existing unverified text |
|
|
| an admin | 403 | apperr.OwnerRequiredErrorMessage |
|
|
|
|
Scenario Outline: Restart is refused with 409
|
|
Given the owner and <condition>
|
|
When the owner sends POST /v1/system/update/restart
|
|
Then the status is 409, the existing marker, result and job are untouched and no new marker is written
|
|
|
|
Examples:
|
|
| condition |
|
|
| can_apply is false (no update-helper.json) |
|
|
| the job state is downloading |
|
|
| the job state is verifying |
|
|
| a marker is already pending |
|
|
| the result file reads "running" (helper at work) |
|
|
|
|
Scenario: Two restarts at once write one marker
|
|
When two owners send POST /v1/system/update/restart concurrently
|
|
Then exactly one answers 202 and the other 409 and one marker exists
|
|
|
|
Scenario: The marker cannot be written
|
|
Given the data directory is not writable, or a directory sits where the marker file goes
|
|
When the owner sends POST /v1/system/update/restart
|
|
Then the status is 500 with a plain text body without paths, no marker exists and the job record is untouched
|
|
|
|
Scenario Outline: GET derives the state from the files and never changes them
|
|
Given <files>
|
|
When any verified user sends GET /v1/system/update twice
|
|
Then both answers are identical, state is <state>, error is <error> and finished_at is <finished>
|
|
And no file in the data directory changed
|
|
|
|
Examples:
|
|
| files | state | error | finished |
|
|
| a marker is present | restarting | null | null |
|
|
| result "running" written 30 s ago | restarting | null | null |
|
|
| result "running" written 6 minutes ago, no marker | failed | "install" | its value |
|
|
| result "succeeded", kind "update", tag equal to the running version | succeeded | null | its value |
|
|
| result "succeeded", kind "update", tag older than the running one | idle | null | its value |
|
|
| result "succeeded", kind "restart" | idle | null | its value |
|
|
| result "rolled_back" | failed | "rolled_back" | its value |
|
|
| result "failed" | failed | "install" | its value |
|
|
| no marker, no result | idle | null | null |
|
|
| a corrupt result file | idle | null | null |
|
|
|
|
Scenario: The result lives until the next job
|
|
Given a result "rolled_back"
|
|
When the owner sends POST /v1/system/update/download and the job reaches "ready"
|
|
Then the result file was deleted by the POST, GET reports state "ready", error null and finished_at null
|
|
And GET /v1/system/update still has exactly the 12 keys of slice 1 plus finished_at
|
|
|
|
Scenario: After a successful update the status is consistent
|
|
Given a result "succeeded" for "v2.3.0-beta" and the running version "v2.3.0-beta"
|
|
Then GET reports state "succeeded", available false, current "v2.3.0-beta" and finished_at set
|
|
|
|
Scenario: The server writes update-running.json at startup
|
|
When the server starts with version "v2.3.0-beta"
|
|
Then update-running.json holds {"version":"v2.3.0-beta","pid":<its pid>,"started_at":<now>} written atomically
|
|
And it is written after the listener is bound and before requests are served
|
|
And a write error is logged and the server still starts
|
|
And a second start replaces the file with the new pid and started_at
|
|
And the file is not served by any route
|
|
|
|
Scenario: Healthz is unchanged
|
|
When a client sends GET /healthz
|
|
Then the status is 200, the body is "ok" and there is no version header, and the route stays public
|
|
|
|
Scenario Outline: The command dispatcher
|
|
When the binary is run with "<args>" and an empty environment
|
|
Then <outcome>
|
|
|
|
Examples:
|
|
| args | outcome |
|
|
| --version | it prints the version, exits 0 (unchanged from slice 2) |
|
|
| enable-browser-updates | it runs the installer, never reads .env or opens the database |
|
|
| disable-browser-updates | it runs the uninstaller, never reads .env or opens the database |
|
|
| apply-update | it runs the helper, never reads .env or opens the database |
|
|
| no arguments | the normal server start |
|
|
| an unknown subcommand | a usage message on stderr and a non-zero exit, the server is not started |
|
|
|
|
Scenario Outline: enable-browser-updates refuses when it cannot work
|
|
Given <situation>
|
|
When "renewcms enable-browser-updates" runs
|
|
Then it exits non-zero with the clear message "<message>" and writes nothing
|
|
|
|
Examples:
|
|
| situation | message |
|
|
| the OS is not Linux | Browser updates need Linux with systemd. |
|
|
| Linux without systemd (no /run/systemd/system) | Browser updates need systemd, which this machine is not running. |
|
|
| not run as root | Run this command as root, for example with sudo. |
|
|
| no unit for the service and no flags | Could not find the RenewCMS service. Pass --service, --binary and --data-dir. |
|
|
| the data directory cannot be resolved | Could not find the data directory. Pass --data-dir. |
|
|
|
|
Scenario: enable-browser-updates installs the units
|
|
Given systemd on Linux, root, and an existing renewcms.service with ExecStart=/opt/renewcms/renewcms and ReadWritePaths=/var/lib/renewcms
|
|
When "renewcms enable-browser-updates" runs
|
|
Then it reads the service name, binary path and data directory from the unit, with --service, --binary and --data-dir overriding them
|
|
And it writes renewcms-update.path (PathExists= the marker) and renewcms-update.service (Type=oneshot, User=root,
|
|
ExecStart=<binary> apply-update with the service, binary, data directory and port as flags)
|
|
And the port comes from --port, else from PORT in the service's environment file, else 8080
|
|
And it runs daemon-reload and enables and starts the path unit
|
|
And it writes update-helper.json last, so can_apply becomes true only when everything else worked
|
|
And no secret and no environment value is written into either unit
|
|
And it prints what it installed and how to undo it
|
|
|
|
Scenario: enable-browser-updates is idempotent
|
|
Given it ran once
|
|
When it runs again, including after the binary path or service name changed
|
|
Then the units and the status file are rewritten to the current values, no duplicate unit exists and the exit is 0
|
|
|
|
Scenario: enable-browser-updates undoes its own partial work
|
|
Given writing the second unit, daemon-reload or enable fails
|
|
Then the first unit is removed, update-helper.json is not written and the exit is non-zero with the reason
|
|
|
|
Scenario: disable-browser-updates
|
|
Given browser updates are enabled
|
|
When "renewcms disable-browser-updates" runs
|
|
Then the path unit is stopped and disabled, both unit files and update-helper.json are removed, daemon-reload runs
|
|
And the marker and result files, the staged files and backups are left in place
|
|
And running it again, or where it was never enabled, exits 0 with a message
|
|
And can_apply reads false afterwards
|
|
|
|
Scenario: apply-update, a plain restart
|
|
Given a marker of kind "restart" and update-running.json with pid 100 and started_at T0
|
|
When the helper runs
|
|
Then it reads the marker without following symlinks, deletes it, and writes the result "running" with started_at
|
|
And it records the current update-running.json, restarts the service once and polls until /healthz answers 200
|
|
and update-running.json is new (pid differs from 100, or started_at is later than the restart instant)
|
|
And it then writes "succeeded" with kind "restart" and finished_at
|
|
And the binary and the staged files are untouched
|
|
|
|
Scenario Outline: A stale running file never counts as success
|
|
Given a marker and update-running.json that <staleness> while /healthz answers 200
|
|
When the helper polls
|
|
Then it keeps polling and it is not declared succeeded or rolled back until a new file appears or 60 s pass
|
|
|
|
Examples:
|
|
| staleness |
|
|
| still holds the old pid and old started_at |
|
|
| holds the target version but the old pid and an old started_at |
|
|
| is missing |
|
|
| is corrupt |
|
|
| holds the old version with a new pid (for an update) |
|
|
|
|
Scenario: apply-update, an update, happy path
|
|
Given a marker of kind "update" for "v2.3.0-beta" and a staged binary, checksums.txt and checksums.txt.sig under updates/v2.3.0-beta/
|
|
When the helper runs
|
|
Then it creates a fresh root-owned temp directory with mode 0700 and copies the staged files into it, opening each original with no-follow
|
|
And it verifies the signature of the COPIED checksums.txt with the embedded public key
|
|
And it verifies the SHA-256 of the COPIED binary against its checksums.txt line, ignoring the earlier job record
|
|
And it copies the current binary to <name>.previous, replacing an older .previous
|
|
And it writes the verified copy to a temp file in the binary's directory (mode 0755), checks that it still hashes to the verified value,
|
|
and installs it with an atomic rename; the original staged path is never installed
|
|
And it restarts the service and polls /healthz and update-running.json for up to 60 s
|
|
And when /healthz answers 200 and update-running.json is new and holds "v2.3.0-beta" it writes "succeeded", success being declared on the
|
|
first matching poll
|
|
And it removes the temp directory and updates/v2.3.0-beta/
|
|
And the marker was deleted before any other step ran
|
|
|
|
Scenario Outline: apply-update refuses an untrusted staged binary
|
|
Given a marker of kind "update" and <fault>
|
|
When the helper runs
|
|
Then the current binary is not touched, no .previous is written and the service is not restarted
|
|
And it writes "failed", logs the technical reason only, and removes the temp directory and updates/<tag>/
|
|
|
|
Examples:
|
|
| fault |
|
|
| the binary was changed after the job verified it |
|
|
| checksums.txt was changed |
|
|
| the signature is from a different key or is missing |
|
|
| checksums.txt has no line for the asset |
|
|
| the staged binary is missing |
|
|
|
|
Scenario Outline: apply-update refuses symlinks
|
|
Given a marker of kind "update" and <symlink>
|
|
When the helper runs
|
|
Then it never reads through the link, the current binary is untouched, there is no .previous and no restart
|
|
And it writes "failed" and logs which path was a symlink
|
|
And whatever the link pointed to is not read, copied, written or removed
|
|
|
|
Examples:
|
|
| symlink |
|
|
| the marker itself is a symlink |
|
|
| <data>/updates is a symlink to another directory |
|
|
| <data>/updates/<tag> is a symlink to another directory |
|
|
| the staged binary is a symlink to /usr/bin/something |
|
|
| checksums.txt is a symlink |
|
|
| checksums.txt.sig is a symlink |
|
|
| a symlink is placed at the result path or at a temp file name |
|
|
|
|
Scenario: A symlinked marker is removed, not followed
|
|
Given the marker is a symlink to a file outside the data directory
|
|
When the helper runs
|
|
Then the link itself is unlinked, the target is untouched, and the result is "failed"
|
|
|
|
Scenario: A file swapped after verification is not installed
|
|
Given the staged binary is verified and a fake attacker replaces the original staged path with other bytes right after the copy step
|
|
When the helper installs
|
|
Then the installed bytes equal the verified copy's bytes and not the swapped bytes
|
|
And the same holds for a swap during the .previous copy and the final rename
|
|
And a swap of the temp file in the binary's directory before the rename is caught by the re-hash and ends as "failed" with the binary untouched
|
|
|
|
Scenario: Result and temp files are written without following links
|
|
Given the service user placed a symlink at update-result.json or at a predictable temp name in the data directory
|
|
When the helper writes its result
|
|
Then it creates a temp file with create-exclusive and no-follow, then renames it over the result, and the link target is untouched
|
|
|
|
Scenario Outline: apply-update distrusts the marker
|
|
Given a marker whose tag is <tag>
|
|
When the helper runs
|
|
Then it writes "failed", the binary is untouched, the service is not restarted and nothing outside <data>/updates is read
|
|
|
|
Examples:
|
|
| tag |
|
|
| ../../etc/passwd |
|
|
| v2.3.0-beta/../../x |
|
|
| an empty string |
|
|
| v2.1.0-beta (older than the running version) |
|
|
| not-a-version |
|
|
|
|
Scenario Outline: apply-update rolls back when the new version does not come up
|
|
Given an update marker and <fault> after the new binary was installed and the service restarted
|
|
When the helper runs
|
|
Then within the 60 s window it restores <name>.previous over the binary atomically and restarts the service again
|
|
And it polls until /healthz answers 200 and a NEW update-running.json holds the old version
|
|
And it writes "rolled_back" with from_version and tag and removes the temp directory and the staged files
|
|
|
|
Examples:
|
|
| fault |
|
|
| /healthz never answers within 60 s |
|
|
| /healthz answers but update-running.json stays old |
|
|
| update-running.json holds another version |
|
|
| the service restart command fails |
|
|
|
|
Scenario Outline: apply-update failures around the swap
|
|
Given an update marker and <fault>
|
|
Then <outcome>
|
|
|
|
Examples:
|
|
| fault | outcome |
|
|
| copying to .previous fails | the binary is untouched, the service not restarted, result "failed" |
|
|
| the atomic install fails | .previous and the old binary are intact, no restart, result "failed" |
|
|
| the rollback restore itself fails | result "failed", logged loudly, exit non-zero |
|
|
| the old version never returns after rollback | result "failed" (not "rolled_back"), exit non-zero |
|
|
|
|
Scenario: The result is always written
|
|
Given any marker and any outcome, including a panic in the helper
|
|
Then update-result.json holds outcome, kind, tag, from_version, started_at and finished_at, written atomically
|
|
And a "running" record exists from the moment the marker was read until the outcome replaces it
|
|
|
|
Scenario: Only the helper runs with privilege
|
|
Then the app has no code that execs systemctl, writes outside the data directory or reads the units
|
|
And the oneshot service and path unit contain no environment secrets
|
|
|
|
Scenario: Settings, owner, Restart buttons (route /settings)
|
|
Given the owner and can_apply true
|
|
Then with state "ready" the Restart button (power, primary) is enabled and opens the Install dialog
|
|
And with state "idle" (Up to date or Check failed) the Restart button (power, secondary) is enabled and opens the Plain restart dialog
|
|
And with state "downloading", "verifying" or "restarting" Restart is disabled or absent as the card draws it
|
|
And with can_apply false (Not prepared) or the admin view no Restart is rendered
|
|
And the slice 2 disabled Restart in Ready to install is now enabled and has a handler
|
|
And the SPA sends {"kind":"update"} from the Install dialog and {"kind":"restart"} from the Plain restart dialog, always
|
|
|
|
Scenario: Settings, Restart: confirm (Install dialog)
|
|
When the owner presses Restart in Ready to install
|
|
Then a dialog titled "Restart to finish the update?" shows "RenewCMS will install version 2.3.0-beta and restart. Your site will be unavailable for about 10 seconds. This page reloads on its own when the site is back. Save anything you're editing first."
|
|
And its buttons are "Restart later" and "Restart now", the confirm is neutral, not red
|
|
And focus moves to the first button, Escape and "Restart later" close it and focus returns to Restart
|
|
And no request is sent until "Restart now"
|
|
|
|
Scenario: Settings, Plain restart: confirm
|
|
When the owner presses Restart with no update waiting
|
|
Then a dialog titled "Restart the site?" shows "Your site will be unavailable for about 10 seconds. This page reloads on its own when the site is back. Save anything you're editing first."
|
|
And its buttons are "Cancel" and "Restart site", with the same focus and Escape behaviour
|
|
|
|
Scenario: Settings, Restart: request failed
|
|
Given the confirm button is pressed and POST /v1/system/update/restart answers 500 or never reaches the server
|
|
Then the dialog stays open (install or plain) with the error "Couldn't start the restart. Nothing was changed and your site is still running. Try again in a moment."
|
|
And the confirm button is enabled again, no overlay shows and nothing is stored in sessionStorage
|
|
|
|
Scenario: Settings, this tab remembers that it started the restart
|
|
Given POST /v1/system/update/restart answers 202 with started_at "S"
|
|
Then sessionStorage holds one entry with the kind and "S" (the server's started_at), and no other storage is written
|
|
And the overlay shows
|
|
|
|
Scenario: Settings, Restarting to install
|
|
Given POST /v1/system/update/restart answers 202 for an update
|
|
Then a full-page region with role "status" shows, titled "Installing version 2.3.0-beta" with
|
|
"Your site is restarting with the new version. This takes about 10 seconds. This page reloads on its own when the site is back." and a moving bar
|
|
And it is announced once as "Installing version 2.3.0-beta. Your site is restarting."
|
|
And the overlay survives failing requests and the Offline banner state is ignored while it shows
|
|
And it polls GET /healthz and GET /v1/system/update every second, tolerating network errors and non-200 answers
|
|
|
|
Scenario: Settings, Plain restart: restarting
|
|
Given POST /v1/system/update/restart answers 202 for a plain restart
|
|
Then the overlay shows "Restarting your site" / "This takes about 10 seconds. This page reloads on its own when the site is back."
|
|
And it polls the same way
|
|
|
|
Scenario: Settings, Restarting, taking longer
|
|
Given 60 seconds pass with no answer from /healthz or from GET /v1/system/update
|
|
Then the overlay shows "Still restarting" / "This is taking longer than usual. Keep this page open. It reloads on its own when the site is back, or you can reload it now." and a "Reload page" button
|
|
And the meta reads "Started at 09:51 · 1 minute ago" (clock-sensitive)
|
|
And "Reload page" reloads the page, the overlay stays until the site answers, and the polling continues
|
|
|
|
Scenario: Settings, the overlay ends when the site answers
|
|
Given the overlay shows and /healthz answers and GET /v1/system/update answers with a state other than "restarting"
|
|
and finished_at later than the stored started_at
|
|
Then the page reloads once
|
|
And a GET answering "restarting", a GET whose finished_at is null or not later than the stored started_at, a /healthz answer without a GET
|
|
answer, and a rejected GET all keep the overlay and do not reload
|
|
|
|
Scenario: Settings, Update done (the tab that started it)
|
|
Given the page reloaded, sessionStorage holds {kind "update", started_at "S"} and GET answers state "succeeded" with finished_at later than "S"
|
|
Then the entry is cleared, focus lands on the "Updates" heading (id="updates-h") with the ring shown
|
|
And a success toast "Update installed" / "RenewCMS is now on version 2.3.0-beta." is announced
|
|
And the Version card shows the new running version and the card reads "You're on version 2.3.0-beta" /
|
|
"The update is installed and your site is running again." / "Updated today at 09:52" with a "Read the release notes" link (arrow-up-right)
|
|
|
|
Scenario: Settings, Update failed, rolled back (the tab that started it)
|
|
Given the page reloaded, sessionStorage holds {kind "update", started_at "S"} and GET answers state "failed", error "rolled_back", finished_at later than "S", running "v2.2.0-beta"
|
|
Then the entry is cleared and focus lands on "Updates"
|
|
And an error toast (stays until dismissed) with icon circle-x "The update didn't install" / "Your site is back on v2.2.0-beta." shows
|
|
And the card shows icon triangle-alert (warning) "The update didn't install" /
|
|
"RenewCMS put the previous version back, so your site is running as before. Nothing was lost." /
|
|
"What to do next: try again in a few minutes. If it fails again, ask whoever manages your server to check the update." and a "Try again" button that sends POST /v1/system/update/download
|
|
And error "install" renders the same card and toast
|
|
|
|
Scenario: Settings, Plain restart: done (the tab that started it)
|
|
Given the page reloaded, sessionStorage holds {kind "restart", started_at "S"} and GET answers state "idle" with finished_at later than "S"
|
|
Then the entry is cleared, focus lands on "Updates" and a success toast "Site restarted" / "Your site is running again." is announced
|
|
And the card is the normal Up to date card
|
|
|
|
Scenario Outline: A later visit shows the card with no toast and no focus move
|
|
Given sessionStorage has no entry, or an entry whose started_at is not earlier than finished_at, and GET answers <result>
|
|
Then the card renders for that state, no toast shows and focus does not move to "Updates"
|
|
And nothing is written to sessionStorage
|
|
|
|
Examples:
|
|
| result |
|
|
| state "succeeded", finished_at set |
|
|
| state "failed", error "rolled_back" |
|
|
| state "failed", error "install" |
|
|
| state "idle", finished_at set (plain restart) |
|
|
|
|
Scenario: Settings, another owner's tab never takes the toast
|
|
Given owner B has /settings open, with no sessionStorage entry, while GET answers "restarting" and later "succeeded"
|
|
Then owner B's page shows the overlay while "restarting" and the card afterwards, with no toast and no focus move
|
|
And owner A's tab, which holds the entry, still gets the toast and the focus
|
|
And an admin sees the admin view and no overlay
|
|
|
|
Scenario: Settings, a stale sessionStorage entry
|
|
Given an entry left behind by a restart that never finished in this tab (the tab was closed and reopened by hand)
|
|
When the page loads and GET answers a finished_at that is not later than the entry's started_at, or null
|
|
Then no toast shows, focus does not move, the entry stays until a later finished_at consumes it, and a new restart overwrites it
|
|
|
|
Scenario: Settings, 409 on Restart
|
|
Given POST /v1/system/update/restart answers 409
|
|
Then the dialog closes, nothing is stored in sessionStorage and the card reloads
|
|
And when the reload shows downloading, verifying or restarting an info toast "An update is already running" / "Another owner started it. Progress shows here." shows and the card or overlay switches to that run
|
|
And when the reload shows can_apply false the card shows "Not prepared" and no toast
|
|
And when the reload shows a different "Ready to install" or "idle" (the kind did not match) the card shows that state and no toast
|
|
|
|
Scenario: Settings, 400 on Restart
|
|
Given POST /v1/system/update/restart answers 400
|
|
Then the dialog shows the "Couldn't start the restart" text and nothing is stored in sessionStorage
|
|
|
|
Scenario: Settings, 403 role changed on Restart
|
|
Given POST /v1/system/update/restart answers 403
|
|
Then the dialog closes, an error toast "Only the owner can do this" / "Ask the owner of this site to update RenewCMS." shows and the card reloads in the admin view
|
|
|
|
Scenario: Settings, 401 on Restart
|
|
Given POST /v1/system/update/restart answers 401
|
|
Then the global handler goes to /login?redirect=/settings&reason=expired and no local copy shows
|
|
|
|
Scenario: Home banner while restarting
|
|
Given state "restarting"
|
|
Then Home shows no update banner and does not poll
|
|
|
|
Scenario: The docs gain a "Browser updates" section
|
|
Then docs/deployment.md has "Browser updates" with the one-time command "sudo renewcms enable-browser-updates", what it installs
|
|
(two units, update-helper.json), how to undo it ("sudo renewcms disable-browser-updates"), and what is and is not supported
|
|
And it lists: Linux with systemd only; not Windows, macOS, Docker or other init systems; the previous binary is kept as <name>.previous
|
|
and a database backup in backups/; an update whose new version does not come up within 60 s is rolled back automatically
|
|
And it names the files update-restart-request.json, update-result.json, update-helper.json and update-running.json
|
|
And the "How to update" link of the Not prepared card points at that section
|
|
And the sentence "the site does not update itself" in the "Update checks" section is replaced
|