gsadmin/sencho
1
0
Fork 0
mirror of https://github.com/Studio-Saelix/sencho.git synced 2026-08-10 02:41:14 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(image-updates): explain persistent digest rebuilds after update (#1784)

Browse Source 
* fix(image-updates): explain persistent digest rebuilds after update

When an update completes but a same-tag digest rebuild is still detected,
the generic "update still detected" warning told operators nothing about
why. The digest comparison already knows the remaining updates are
digest-only (no higher tag), so recheckStack now returns a targeted
warning naming the two daemon-side causes: a registry mirror or cache
serving stale content, or a container still pinned to the previous image.

The digest-rebuild badge surfaces (Anatomy banner, Fleet cards, mobile)
now carry a tooltip with the same explanation, and the post-update
warning is added to the pre-update refresh sanitization set.

* fix(image-updates): surface digest warnings on editor and mobile paths

Editor Update discarded recheckWarning, digest hints were hover-only, and
service-scoped rechecks blamed the daemon when only sibling services remained stale.
This commit is contained in:
Anso
2026-08-06 09:22:53 -04:00
committed by GitHub
parent 575848e017
commit 4fa532530e
13 changed files with 346 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/auto-update-policies.mdx
+3
View File
@@ -173,6 +173,9 @@ A stack that mixes registry images and `build:` services still gets a card, scor
<Accordion title='Apply now finished but the readiness card still shows a newer tag'>
Compose still pins the older tag. Apply pulls and recreates that pinned tag only. To move to the next tag shown on the card, edit the Compose `image:` reference, then deploy.
</Accordion>
<Accordion title='Apply now finished but the digest rebuild badge stays'>
The badge means new image content is published behind the same tag. If an update does not clear it, your Docker daemon may be pulling through a registry mirror that still serves the old content, or the container may still run the previous image. Check your daemon configuration for a `registry-mirrors` entry, or recreate the service with `docker compose up -d --force-recreate` on the affected stack.
</Accordion>
<Accordion title='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.
</Accordion>