mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-07 01:14:14 +00:00
Anso
af9cb0aa63
* feat(auto-update): add per-stack auto-update enable/disable toggle Paid users (Skipper and Admiral) can now opt individual stacks out of scheduled auto-updates from the stack context menu without disabling the global feature. - Add stack_auto_update_settings table (node_id, stack_name) with default enabled=true; four typed DatabaseService accessors with parameterized queries. - Add GET /stacks/auto-update-settings, GET /stacks/:name/auto-update, and PUT /stacks/:name/auto-update (requirePaid + requireAdmin). PUT broadcasts state-invalidate with action auto-update-settings-changed so all open tabs refresh immediately. - Stack DELETE clears the auto-update setting row alongside stack_update_status. - autoUpdateRouter /execute skips disabled stacks before any registry call; skip is recorded in the results array. Manual Update actions are not affected. - Add Auto-update: Enabled/Disabled toggle in the stack inspect group (paid tiers only, hidden for Community, consistent with Auto-Heal). Toggle uses optimistic update with revert-on-error toast. - AutoUpdateReadinessView shows an Auto: Off pill and disables the Apply now button for stacks with auto-updates off. Detection still runs so the readiness card remains visible. - Add 21 backend Vitest tests covering DB round-trips, endpoint auth and tier gates, execute skip for both wildcard and named targets. Add 3 frontend hook tests for toggle visibility and callback behavior. * docs(auto-update): document per-stack auto-update control Add a Per-stack control section to the auto-update readiness page explaining how to disable and re-enable auto-updates for individual stacks, what disabling means (scheduled apply skipped; detection still runs; manual update unaffected), and a troubleshooting entry for scheduled runs not applying to a specific stack.
127 lines
8.4 KiB
Plaintext
127 lines
8.4 KiB
Plaintext
---
|
|
title: "Auto-Update Readiness"
|
|
description: "Review pending container updates across your fleet, with risk tags, changelogs, and rollback targets, before applying."
|
|
---
|
|
|
|
<Note>
|
|
Auto-Update Readiness requires a **Skipper** or **Admiral** license.
|
|
</Note>
|
|
|
|
## Overview
|
|
|
|
Auto-Update Readiness is the launchpad for every pending update across your stacks. Instead of a list of CRUD policies, the view surfaces one card per stack with an available update and tells you, at a glance, whether it is safe to apply.
|
|
|
|
Each card shows:
|
|
|
|
- The current and next tag, with the new version highlighted in cyan.
|
|
- A **risk tag** derived from the version delta: `patch` (safe), `minor`, `major`, or `digest rebuild`.
|
|
- A one-line changelog preview when the registry publishes one.
|
|
- The **rollback target** (the tag Sencho will fall back to if an update is reverted).
|
|
- The next scheduled run for the matching auto-update task, if one exists.
|
|
|
|
<Frame>
|
|
<img src="/images/auto-update/readiness-board.png" alt="Readiness board with hero count, per-stack cards, and risk tags" />
|
|
</Frame>
|
|
|
|
The hero at the top counts pending updates across every node in your fleet and tells you how many of them are ready to apply without human review. Major version jumps and stacks with blocked registries are counted separately so they can be reviewed before the scheduler runs.
|
|
|
|
Cards are grouped by node, with a section header for each node that has at least one pending update. The local node is listed first, followed by remote nodes alphabetically. If any of your online nodes is unreachable when the page loads, a small line under the hero shows how many of your online nodes responded.
|
|
|
|
## Workflow
|
|
|
|
1. Open the **Auto-Update** view from the sidebar.
|
|
2. Skim the card grid. Patch and minor bumps render with a green or amber tag; major bumps render in red and are marked as blocked.
|
|
3. For a safe update, click **Apply now** on the card to pull and recreate the stack immediately.
|
|
4. For a major bump, review the changelog preview and the rollback target before deciding. If you still want to apply it, switch to the **Schedules** view and create or edit an auto-update task for that stack.
|
|
5. Use **Recheck** in the hero to force an immediate registry poll across every reachable node. Per-node cooldowns still apply, and the toast tells you how many nodes were triggered, rate-limited, or failed.
|
|
|
|
## Risk tags
|
|
|
|
| Tag | Meaning | Source |
|
|
|-----|---------|--------|
|
|
| **patch** | Safe automated update (e.g. `1.2.3` → `1.2.4`) | Semver comparison of tags |
|
|
| **minor** | Backwards-compatible update (e.g. `1.2.3` → `1.3.0`) | Semver comparison of tags |
|
|
| **major** | Potentially breaking change (e.g. `1.2.3` → `2.0.0`). Marked **blocked** by default | Semver comparison of tags |
|
|
| **digest rebuild** | Same tag, new image digest (e.g. `latest` pushed again) | Local vs remote digest diff |
|
|
| **unknown** | Non-semver tag (e.g. `main`, `stable`) | Fallback when tags cannot be compared |
|
|
|
|
Blocked updates still schedule check runs, but the apply button is disabled until you review them manually.
|
|
|
|
## Per-stack control
|
|
|
|
Auto-updates can be disabled on a per-stack basis from the stack's context menu. This lets you keep the global schedule active while opting specific stacks out of unattended updates, such as databases, self-built images, or any stack pinned to a fixed tag.
|
|
|
|
### Disabling auto-updates for a stack
|
|
|
|
1. Right-click the stack in the sidebar, or open the kebab menu (three dots).
|
|
2. In the **Inspect** group, click **Auto-update: Enabled** to toggle it off. The label changes to **Auto-update: Disabled** and the icon switches to a slash-circle.
|
|
3. The setting persists across restarts. The readiness board shows an **Auto: Off** pill on that card, and the **Apply now** button is disabled with the tooltip "Auto-updates are disabled for this stack. Update it from its actions menu."
|
|
|
|
<Note>
|
|
Per-stack auto-update control requires a **Skipper** or **Admiral** license. The toggle does not appear on Community.
|
|
</Note>
|
|
|
|
### What disabling means
|
|
|
|
- **Scheduled and fleet-wide auto-update runs skip the stack entirely.** No registry call is made, and no image update is applied automatically.
|
|
- **Image update detection still runs.** The sidebar dot and the readiness card still reflect whether an update is available. You are informed; the system just does not apply it for you.
|
|
- **Manual updates are unaffected.** You can still click **Update** in the lifecycle menu (or **Deploy**) to apply an update on demand. Per-stack control governs only the automated path.
|
|
|
|
### Re-enabling
|
|
|
|
Open the same menu and click **Auto-update: Disabled** to toggle it back on. The next scheduled run will include the stack again.
|
|
|
|
## Scheduling auto-updates
|
|
|
|
Auto-update is a first-class action in the Schedules view. To create a recurring check for a stack:
|
|
|
|
1. Open **Schedules** in the top nav.
|
|
2. Click **New Schedule**.
|
|
3. Set **Action** to **Auto-update Stack**, choose the target node and stack, pick a cron expression, and save.
|
|
|
|
The task lives alongside restart, prune, snapshot, and scan tasks in the same timeline and table. Run history, notifications, and the Run Now button behave the same as for every other scheduled action. See [Scheduled Operations](/features/scheduled-operations) for details.
|
|
|
|
## Multi-node support
|
|
|
|
The readiness board shows pending updates from every node in your fleet in a single view, regardless of which node is selected in the sidebar. You do not need to switch nodes to inspect what is pending elsewhere.
|
|
|
|
Each node group renders its own card grid. **Apply now** runs on the node that owns the stack, and **Recheck** fans out to every reachable node so registries get polled in parallel. Sencho handles the routing through the Distributed API; no additional configuration is needed.
|
|
|
|
## How readiness is computed
|
|
|
|
For each stack with a pending image update, Sencho computes a preview by:
|
|
|
|
1. Parsing the compose file to enumerate every pullable image reference.
|
|
2. Calling the registry with your configured credentials to fetch the current tag list and remote digest.
|
|
3. Picking the highest semver tag greater than the current tag (keeping the same prefix and suffix) or, if tags match but digests differ, treating it as a digest rebuild.
|
|
4. Scoring the overall stack by the most severe image bump. Any major bump marks the stack as blocked.
|
|
5. Deriving the rollback target from the running tag and normalizing Docker Hub library paths.
|
|
|
|
The preview is recomputed each time the readiness board loads, so it reflects the live state of your registries and local images.
|
|
|
|
## Troubleshooting
|
|
|
|
### Card shows "No changelog available"
|
|
|
|
Sencho reads changelog metadata from the registry's manifest and OCI annotations. Registries that do not publish this metadata (most private registries and many self-hosted ones) will simply render the card without a changelog. The risk tag is still accurate because it is computed from the tag itself.
|
|
|
|
### Apply button is disabled with a "blocked" tooltip
|
|
|
|
The stack has a major version bump. Open the cron schedule for that stack and apply manually after reviewing the upstream release notes. The block is a policy decision: major updates never auto-apply without human review.
|
|
|
|
### Card stays stuck on "Checking"
|
|
|
|
The registry call is either still pending or failed. Click **Recheck** in the hero to retry. If the stack has private-registry credentials, confirm they are still valid in **Settings > Registries**.
|
|
|
|
### "Nothing to update" but I see an update on another view
|
|
|
|
Image update detection runs every six hours on each node. The readiness board uses the same cached status. Trigger **Recheck** to force a fresh check across every reachable node, or see [Image update detection](/features/image-update-detection) for details on the refresh cycle.
|
|
|
|
### Scheduled auto-update runs are not applying to a specific stack
|
|
|
|
The stack likely has auto-updates disabled. Open the stack's kebab menu or right-click context menu and check the **Inspect** group. If the item reads **Auto-update: Disabled**, click it to re-enable. Once re-enabled, the next scheduled run will include the stack, or you can trigger an immediate run from the Auto-Update view.
|
|
|
|
### Banner says "X of Y nodes reachable"
|
|
|
|
One or more nodes that are marked online in your fleet did not respond within the request timeout. Pending updates from those nodes are not shown until they come back. Check the node's status from the Fleet view and the network path between this Sencho instance and the unreachable node.
|