Repository navigation
Plugin system update
Checks, installs and safely rolls back OSPy updates from stable or beta Git branches with backup and watchdog protection.
| Item | Value |
|---|---|
| Version | 1.2.8 |
| Category | Network, data and system maintenance |
| Author | Martin Pihrt |
| License | GPL-3.0 |
| OSPy |
3.0.211 or newer |
| Python |
3.8 or newer |
| Permissions |
email, files, network, subprocess, system
|
| Hardware | No dedicated hardware requirement declared |
| Dependencies | None |
| Python/OS packages | None |
| Interfaces | Mobile API v1 |
| Source | Open the plug-in directory |
Checks, installs and safely rolls back OSPy updates from stable or beta Git branches with backup and watchdog protection.
Tested in Python 3+
This plugin compares the local copy with the remote repository and can automatically update the local copy. The default Stable update channel follows the tested master branch. The optional Test channel follows beta and receives changes immediately, so it may contain defects. The selected channel is displayed in the plug-in status and Diagnostics and is used by both manual and automatic updates. Switching back to Stable explicitly returns OSPy to master. The repository owner must create and maintain the remote beta branch. If it does not exist, the check fails visibly and no update or branch change is performed. Before installing an update, the plug-in creates a verified OSPy system safety backup. If that backup cannot be created, the update is not started. Before changing the Git working tree, the plug-in also starts an external update watchdog. On systemd installations it runs in a separate transient service, so it remains active while OSPy restarts. A non-Python supervisor keeps this protection compatible with legacy SysV OSPy services that broadly terminate Python processes during restart. The helper must publish a token-bound readiness marker before any tracked file is changed. The new OSPy process confirms the update only after a fresh scheduler heartbeat and the web interface starts listening. If a healthy start is not confirmed within 300 seconds, the watchdog resets the repository to the previous commit and restarts OSPy automatically. The five-minute window allows installations with many sequentially initialized plug-ins to reach the System Update confirmation without weakening the health checks. Systems without systemd use a detached supervised helper process. If the watchdog cannot be started or does not confirm readiness, the update is aborted before tracked files are changed. The status page displays the exact current and target commits. A verified stable release must be an annotated Git tag named vX.Y.Z whose commit is reachable from origin/master; its annotation is displayed as the release notes. Lightweight tags, non-semantic names and tags outside master are ignored. The project maintainer creates and pushes release tags manually only after the tested beta revision has been promoted to master. Version 1.2.8 forces GitHub fetch operations to use HTTP/1.1 when HTTP/2 transport fails and preserves the complete Git command output in update diagnostics. It also exposes stable mobile metric identifiers for the current and target commits, update availability and watchdog state so the native application can safely provide check and install controls. The complete stable metric IDs are enabled, automatic_update, checking, update_available, current_version, current_commit, target_commit, stable_release, upstream_branch, update_channel, update_watchdog and last_watchdog_result. The plug-in card is status-only: checking, applying and rolling back updates use OSPy's separately scoped /api/v1/updates/actions/check|apply|rollback endpoints and asynchronous operation polling. Both manual commit rollback and rollback to the latest verified stable release now save the settings, create a verified safety backup and arm the external watchdog before changing Git files. Stable rollback checks out master at the verified tag commit. The plug-in never creates or trusts a release tag supplied by the browser; it refreshes and validates the repository state again when rollback is requested. For check new version OSPy click on update status button. If new version is posible click on update OSPy button. Plugin downloading and installing new version OSPy. Next restarting OSPy service. This plugin allows update itself automatically the system, while allowing send an E-mail to the system administrator.
The plug-in includes a manifest declaring repository-network, Git subprocess, OSPy-file, restart and e-mail access, uses the shared OSPy lifecycle for its checker and manual refresh worker, and reports repository checks, update availability, updates, watchdog and rollback state through the Diagnostics health interface.
-
Use update plugin: If the box is checked, the plugin checks for available system updates every hour.
-
Automatic update: If the box is checked, the plugin will update the system itself
-
Send E-mail if update is available: For this function required E-mail plugin.
-
E-mail subject: The subject of the E-mail being sent.
-
Show in footer: Show data from plugin in footer on home page.
-
Status: Status window from the plugin, including the exact current and target commits and the latest verified stable release.
The following notes are generated from the help page shipped with this plug-in. Field names are also explained directly in the OSPy settings page.
This plugin compares the local copy with the remote repository and can automatically update the local copy
This plugin also allows you to restore a previous version of the OSPy software (you can go back 10 steps)
Before changing OSPy files, the plug-in starts an external watchdog. The updated process confirms a healthy start after the scheduler responds and the web interface is listening. If confirmation is not received within five minutes, the previous commit is restored and OSPy is restarted automatically.
If the external watchdog cannot be started, the update is stopped before tracked files are changed.
The status page shows the exact current and target commits. A verified stable release is an annotated vX.Y.Z Git tag whose commit belongs to the master branch; its tag message is displayed as the release notes.
Rollback to the last verified stable release and manual commit rollback both create a verified safety backup and start the external watchdog before changing OSPy files.
Release tags are created manually by the project maintainer after successful tests. The plug-in does not create release tags.
For check new version OSPy click on update status button
If new version is posible click on update OSPy button. Plugin downloading and installing new version OSPy. Next restarting OSPy service
This plugin allows update itself automatically the system, while allowing send an E-mail to the system administrator
Plugin setup
- Use update plugin
If the box is checked, the plugin checks for available system updates every hour.
- Update channel
Stable is the default channel and follows the tested master branch. Test follows the beta branch and receives changes immediately, but it may contain defects. The selected channel is used for manual and automatic updates, and it can be changed back to stable at any time.
If the remote beta branch does not exist, the repository check reports an error and OSPy is not changed.
- Automatic update
If the box is checked, the plugin will update the system itself.
- Send E-mail if update is available
For this function required E-mail plugin.
- E-mail subject
The subject of the E-mail being sent.
- Show in footer
Show data from plugin in footer on home page.
- Status
Status window from the plugin.
Check OSPy → Diagnostics first and remove passwords, tokens, private addresses and other secrets before sharing logs. Report reproducible plug-in problems in the OSPy-plugins issue tracker.
Start
Reference
Catalog sections