Automatic system updates, with a check and automatic restore

The update API (see the September 30 update) solved the "how". The "when" was still missing: someone had to remember to update. admin-atualizacoes now has two tabs: Manual, with the previous flow, and Automatic.

How the task decides

The task is declared by the module itself in admin-cron and runs every hour, almost always without touching the network:

1. Disabled, it stops. With a pending run, it reads the result: success ends it; an automatic restore or a failure puts the version on the refused list. 2. Outside the preferred hour, or with the period's check (daily, weekly or monthly) up to date, it stops. 3. It looks for the newest stable version and only updates when it is higher than the installed one, is not refused, there is no pending file conflict and the deploy lock is free.

The update follows the same path as the API: snapshot, a check after the swap, and automatic restore of the files if something breaks.

Safeguards

• The configuration lives outside the public area and outside the update package.
• The options passed to the updater come from a closed list in the code. Even by editing the configuration file by hand, nobody can turn off the check or the automatic restore.
• "Check now" shows the available version but does not postpone the next automatic check.
• A refused version can be released from the screen to try again.

Status

Validated in the test environment with automated tests and a browser script (19/19). A real update started by the task itself, both successful and with automatic restore, has not been exercised yet. Acceptance pending.