Issues with GHCR package for nextcloud image

[luoe]

Hello everyone,

I let Renovate fetch updates periodically for Docker images. Renovate fetches updates for images from the default Docker Hub registry, the Github Container Registry and custom registries.
I almost never had issues having renovate fetch images updates for various images, including images from ghcr.io.

However, the image for nextcloud fails from time to time:
Renovate failed to look up the following dependencies: Failed to look up docker package ghcr.io/linuxserver/nextcloud: no-result.

A new run of Renovate usually fixes this problem, but the issue is coming up more frequently the last months.

I also use the lsio MariaDB image from GHCR, but this one never fails to fetch.

Could this be a Github issue or is someone else facing the same problem?

[abbas0444]

This is most likely down to how many tags the nextcloud image has and how Renovate reads tags from GHCR, rather than something wrong with the image itself.

Why nextcloud fails and mariadb doesn't

The GHCR tags API returns at most 1000 tags per request, sorted oldest to newest. Because of that ordering, Renovate's docker datasource fetches every page for ghcr.io images (see hostsNeedingAllPages in lib/modules/datasource/docker/index.ts). Right now:

• ghcr.io/linuxserver/nextcloud: ~4,275 tags, so 5 sequential requests
• ghcr.io/linuxserver/mariadb: ~1,337 tags, so 2 requests

If any one of those requests fails (timeout, throttling, a transient 5xx), the whole lookup fails and you get no-result. A second run usually succeeds, which matches what you see. LinuxServer publishes multi-arch and versioned tags for every build, so the tag count, and with it the chance of a failed page, keeps growing. That fits "more frequent over the last months".

Renovate also only caches the tag list for Docker Hub. For GHCR it downloads all pages again on every run.

Workaround

LinuxServer publishes the same images to Docker Hub. If you switch the reference to:

linuxserver/nextcloud

Renovate uses the Docker Hub tags API instead. That API returns the newest tags first, is cached between runs, and falls back to the registry API if it fails. It is much less likely to hit this.

If you'd rather stay on GHCR, the error is transient, so it's harmless apart from the noise. The next run will pick the update up.

[luoe]

Thank you. This totally makes sense! I will try this and will watch for a couple of days/weeks.
I'll mark your reply as an answer as soon as I can confirm the behaviour.