Docker digest update stuck on a 2-week-old digest for one dependency (proposed a downgrade) [woodpecker autoscaler]

[6543]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.49.0

Please tell us more about your question or problem

Repo: https://github.com/woodpecker-ci/infrastructure

One dependency, woodpeckerci/autoscaler, has been resolving to a stale digest since
2026-08-15. Other dependencies from the same registry, extracted by the same custom
manager, in the same file, in the same run, resolve correctly.

The dependency is declared in host_vars/ci_server.yaml:

# renovate: datasource=docker depName=woodpeckerci/autoscaler versioning=docker
woodpecker_autoscaler_version: next@sha256:e93bd9c3387f04c3a491b925cf50a3b24b57a4ece4454d6b4354ce55bb497f12

It is picked up by a customManagers regex from the shared preset
github>woodpecker-ci/renovate-config
(fileMatch: ["^(group_vars|host_vars)/.+?$"], capturing currentValue and currentDigest).
Repo config: https://github.com/woodpecker-ci/infrastructure/blob/main/.github/renovate.json

docker.io/woodpeckerci/autoscaler:next currently resolves to
sha256:380783db5c0e816d6b5f1ccdabb1a64b24364fb6cedabc6917ee08f969fe1cca
(image created 2026-09-01T01:18:49Z, org.opencontainers.image.revision 28c4846).

Renovate still treats sha256:e93bd9c3... as current. That image was built
2026-08-15T02:18:39Z (revision b24f1002), so the lookup appears frozen roughly 17 days back.

Because the tag lookup is stale, Renovate raised a PR that moved the pin backwards:

• chore(deps): update woodpeckerci/autoscaler:next docker digest to e93bd9c woodpecker-ci/infrastructure#490 (2026-08-30) — 6864fcf → e93bd9c

6864fcf (built 2026-08-24T10:04:27Z, revision b09a243) had been set manually a few days
earlier in woodpecker-ci/infrastructure#488, precisely because Renovate
had stopped bumping it. Merging #490 reverted that manual bump, so main is now pinned to an
older image than before.

An earlier PR, woodpecker-ci/infrastructure#477 (2026-08-15), had already
proposed the same e93bd9c — i.e. Renovate has returned the identical digest for this tag on
every run since.

Logs (if relevant)

https://developer.mend.io/github/woodpecker-ci/infrastructure/-/job/43c48658-bac4-4931-823c-f09a6416b83e

Logs

[infrastructure_2026-09-01_11-10_43c48658-bac4-4931-823c-f09a6416b83e.log.txt](https://github.com/user-attachments/files/31689096/infrastructure_2026-09-01_11-10_43c48658-bac4-4931-823c-f09a6416b83e.log.txt)

[6543]

Follow-up: likely root cause in DockerHubCache

I pulled the job log from the Mend portal and went through it with Claude to correlate it
against the datasource source:

Job: woodpecker-ci/infrastructure, 2026-09-01T11:10Z, Renovate 44.49.0.

What the log establishes

All three :next pinned images are treated as unversioned, so no releases lookup happens for
any of them:

11:10:08.407  Dependency woodpeckerci/autoscaler has unsupported/unversioned value next (versioning=docker)
11:10:08.410  Dependency woodpeckerci/woodpecker-server has unsupported/unversioned value next (versioning=docker)
11:10:08.429  Dependency woodpeckerci/woodpecker-agent has unsupported/unversioned value next (versioning=docker)

Only two of the three produce an update:

11:10:09.810  2 flattened updates found: woodpeckerci/woodpecker-server, woodpeckerci/woodpecker-agent

and in packageFiles with updates the autoscaler dep comes back with an empty update list:

{
  "currentDigest": "sha256:e93bd9c3387f04c3a491b925cf50a3b24b57a4ece4454d6b4354ce55bb497f12",
  "currentValue": "next",
  "datasource": "docker",
  "depName": "woodpeckerci/autoscaler",
  "packageName": "woodpeckerci/autoscaler",
  "warnings": [],
  "updates": []
}

while the two siblings in the same file, same manager, same run get the digests the registry is
actually serving right now (ca7b6b0, b55309f). So getDigest() returned the already-pinned
digest for autoscaler, and no Got docker digest ... line appears for it.

Cache counters for the run:

Package cache statistics     {"get":{"count":38,...},"set":{"count":1,...}}
Datasource cache statistics  {"docker":{"https://index.docker.io":{"hit":0,"miss":0,"set":0,"skip":10}}}

The code path

lib/modules/datasource/docker/index.ts, in _getDigest():

if (!architecture) {
  // Reuse the digest cached from the Docker Hub tag API
  if (registryHost === DOCKER_HUB) {
    const cache = await DockerHubCache.init(dockerRepository);
    const cachedDigest = cache.getDigestForTag(newTag);
    if (cachedDigest) {
      return cachedDigest;
    }
  }

  manifestResponse = await this.getManifestResponse(
    registryHost,
    dockerRepository,
    newTag,
    'head',
  );

architecture is null here: getImageArchitecture() only yields a value when currentDigest
resolves to a single-architecture image manifest, and e93bd9c is an OCI image index
(application/vnd.oci.image.index.v1+json, four real platforms plus attestation manifests).
So the DockerHubCache short-circuit is taken and no registry request is made at all.

Now the part that looks like the actual bug. In dockerhub-cache.ts the entry is persisted for
90 days:

await packageCache.set(
  cacheNamespace,
  this.dockerRepository,
  this.cache,
  3 * 60 * 24 * 30,
);

and reconcile(), the only thing that refreshes those items, is called from exactly one place,
_getDockerHubTags(), which is only reached through getReleases().

For a digest-only dependency pinned to a mutable tag, getReleases() never runs, because the tag
is unversioned. So getDigest() reads the Docker Hub tag cache but nothing on that path ever
writes it. Once an entry exists, a mutable tag can keep returning the digest it had when the
entry was last reconciled, for up to 90 days, without a single registry request.

That matches the observed timeline exactly: e93bd9c is the image built 2026-08-15T02:18:39Z, and
Renovate has returned that same digest on every run since 2026-08-15, including proposing it as an
"update" over a newer digest in #490.

getArchDigestForTag() a few lines further down is read the same way, so the arch-specific branch
looks like it has the same shape.

Why the two sibling deps are fine

This part I can't prove from the outside, only infer: server and agent presumably have no
datasource-docker-hub-cache entry, so getDigestForTag() returns null for them and they fall
through to the real HEAD /v2/<repo>/manifests/next, which is why their digests are correct.
Something must have populated the entry for woodpeckerci/autoscaler on 2026-08-15 and nothing
since. The cache key is the bare repository name with no repo or org scoping, so on the hosted app
that entry is shared by every job that touches woodpeckerci/autoscaler.

If someone with access can dump datasource-docker-hub-cache / woodpeckerci/autoscaler from the
hosted Redis, that should confirm or kill this in one step: I would expect the next item to carry
digest: sha256:e93bd9c3... and a last_updated around 2026-08-15.

Suggested directions

1. Do not serve getDigestForTag() results for a tag whose cached last_updated is older than
   some small TTL, and fall back to the HEAD request instead of returning unconditionally.
2. Or reconcile the Docker Hub cache on the digest-only path too, so mutable tags stay current.
3. Independently: refuse to emit a digest update whose target is older than the currently pinned
   digest. fix(pr): Prevent accidental hyperlinks in PR body #490 silently reverted a manual fix, and a guard there would have caught this class of
   bug regardless of cause.

I leave the suggestons from claude but dont think you as maintainer have to respect them at all. you know your project and guidelines better ;)