mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-10 02:41:14 +00:00
Anso
ccad5c925b
* feat(nodes): hide hub-only views when active node is remote Fleet, Schedules, Audit, Logs, and Auto-Update operate on hub-owned state (node registry, fleet schedules, centralized audit, fleet-wide log aggregation, fleet-wide update preview). When the active node is remote, proxying those surfaces would show that remote's own disconnected state instead of the hub's. Hide them from the nav strip and force-redirect to Home if one was open during the node switch. Backend hubOnlyGuard middleware sits between nodeContextMiddleware and the remote proxy and rejects /api/scheduled-tasks, /api/audit-log, and /api/notification-routes with 403 + HUB_ONLY_ENDPOINT when nodeId resolves to a remote, closing the script-bypass path the UI gating cannot reach. Settings sub-sections were already gated via the hiddenOnRemote registry; this extends the same model to top-level views. * docs(nodes): note hub-only visibility on Fleet, Schedules, Audit, Logs, Auto-Update Each of the five hub-only feature pages now points readers to the canonical "What top-level views show when a remote node is active" section in multi-node.mdx, so users landing directly on a feature page understand why the nav item disappears when they switch to a remote node.
131 lines
8.6 KiB
Plaintext
131 lines
8.6 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>
|
|
|
|
<Note>
|
|
Auto-Update is hub-only and is hidden from the nav strip when a remote node is the active selection. See [Multi-Node Management](/features/multi-node#what-top-level-views-show-when-a-remote-node-is-active).
|
|
</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.
|