[BUG] Stop tag enumeration on Docker Hub 429 causes multi-year back-off in v0.9.x

[gitfeber]

Describe the bug
When running version-checker v0.9.0 or v0.9.1 against Docker Hub without authentication, tag enumeration stops as soon as a 429 Too Many Requests is returned. The process enters an extremely long back-off (e.g. “retrying in 485009h…”), so you only see a small subset of your images in Prometheus. This did not happen in v0.8.6, where all tags were fetched successfully.

To Reproduce

1. Deploy version-checker v0.9.1 with only these args (no --docker-token for Docker Hub):

containers:
- name: version-checker
  image: quay.io/jetstack/version-checker:v0.9.1
  args:
    - "--test-all-containers"
    - "--metrics-serving-address=0.0.0.0:8181"

2. Wait for the first scrape cycle to finish.

3. Inspect the logs and you’ll see entries like:

time="2025-04-30T17:58:52Z" level=info msg="[DEBUG] GET https://registry.hub.docker.com/v2/repositories/bitnami/oauth2-proxy/tags?page=19&page_size=100 (status: 429): retrying in 485009h59m52s (10 left)" client=docker component=client

4. Check Prometheus: only the first pages were fetched; all remaining repositories are missing.

Expected behavior
Version-checker should either retry after a short delay (e.g. a few seconds) and continue enumeration, or upon the first 429, skip only that single request and proceed with the next repository, instead of entering a multi-year back-off.

Screenshots
time="2025-04-30T17:58:52Z" level=info msg="[DEBUG] GET https://registry.hub.docker.com/v2/repositories/bitnami/oauth2-proxy/tags?page=19&page_size=100 (status: 429): retrying in 485009h59m52s (10 left)" client=docker component=client

Environment (please complete the following information):

• Version-Checker: v0.9.0 & v0.9.1
• Kubernetes: v1.31.8
• Prometheus: v3.3.0
• Grafana: v9.5.0
  Container Registry: registry.hub.docker.com (anonymous pull and docker token pull)

Additional context

• In v0.8.6, the complete tag listing worked without any rate-limit interruptions.
• Docker Hub enforces an “abuse limit” on unauthenticated API requests, which currently halts the scan completely when hit.
• A more graceful retry strategy or skipping on 429 would restore full coverage.

[davidcollom]

Hi, thanks for raising this issue, I had noticed this during testing and had repaired #354 in response - This has been merged and I'll work to get a 1.9.2 release out today! 👍

[davidcollom]

@gitfeber - 0.9.2 should now be released, If you could please test and report back if this is resolved so we can keep issues clear it would be great! 👍