Krystie
de3215f704
Previously, /api/v1/updates/available silently skipped any image on a non-Docker-Hub registry (line 154 routing: 'ghcr.io/seerr-team/seerr' has 3 slash-delimited segments → 'Custom registry not yet supported'). Symptoms: 4 of 6 production containers (seerr, albyhub, phoenixd, velxio) all on ghcr.io. UpdateManager would log 'Custom registry not yet supported: ghcr.io/...' and return null. Updates invisible in the Updates modal, even when newer images existed. Fix: - Rewrite image parsing to detect the tag-vs-registry-host colon correctly (lastColon > lastSlash guard, handles ghcr.io:443/path). - Add getGhcrDigest() mirroring the DockerHub pattern, against ghcr.io's OCI distribution endpoint. Same bearer-token auth flow, the existing parseAuthHeader + authenticateAndGetDigest already handle the WWW-Authenticate format ghcr.io returns. - Multiple Accept headers for the response — Docker Hub used manifest.v2 only; GHCR serves manifest.list.v2 for multi-arch tags like ':latest', and the response is the multi-arch manifest itself with the platform-specific digest in the Child header chain. We use the digest from the 'docker-content-digest' response header, which the GHCR endpoint sets even for manifest lists. Verified: UpdateManager log now shows 'Found 6 updates available' on DNS2 (previously 0-2, all from non-Docker-Hub images). /api/v1/updates/available returns entries for seerr, albyhub, etc. Per-tile Update button (core.js:811) + Updates modal Update/Update All (features.js:1508 + L()) are already wired and now functional for all registries.