Disabling digest checks

[depuits]

For my use case I am not realy interested in the digest updates of images. In de documentation I found the DD_WATCHER_{watcher_name}_WATCHDIGEST but this will be removed in v1.6. I only have one container on which I am interested in the digest for updates and if I understand it correctly I would need to add dd.watch.digest to all my containers.

[scttbnsn]

For images with meaningful tags (floating like latest/v3, or fully-pinned like 1.4.5), digest watching is already on by default in v1.6, no config needed. That's shouldWatchDigestForUnlabeledImage in the Docker watcher, and it watches by digest for basically any container with a real tag, not just rolling tags.

So it's backwards from what you're picturing: the one container you care about is almost certainly already getting digest checks with zero labels. The labeling work you'd actually be signing up for is the opposite: dd.watch.digest=false on the containers you don't care about, to turn it off for those.

And yeah, there's no global switch for that default anymore. DD_WATCHER_{watcher_name}_WATCHDIGEST is gone in v1.6 (rejected outright, not silently ignored) and nothing replaced it at the watcher level. It's per-container label or per-image now.

If the containers you don't care about share images, you don't have to label each one individually. DD_WATCHER_{watcher_name}_IMGSET_{imgset_name}_WATCH_DIGEST=false matched by image name covers a whole group with one env var. Otherwise it's dd.watch.digest=false per container.

Worth being straight about the gap: there's genuinely no one-liner for "off everywhere except this one image." Closest is imgset grouping. If most of what you run is the same handful of images that's not bad, but if it's a pile of one-offs it is real per-container work.

[depuits]

For images with meaningful tags (floating like latest/v3, or fully-pinned like 1.4.5), digest watching is already on by default

I would expect digest watching for tags like latest or only major version but not if I use a fully-pinned tag like 1.4.5. The thing I am experiencing now is digest updates for images with latest and fully pinned tags. I do use a lot alpine versions of the images (eg 1.4.5-alpine) but i also get digest updates on regular tags.

Following tags al show a digest update:

• 18.4-alpine
• latest
• 34.0.2
• 2.0.22
• v7.3.0-bookworm

[depuits]

I am currently running version 1.5.2 of drydock, not sure if the complete behavior of this is changed in 1.6?

[scttbnsn]

Nothing changed between 1.5.2 and 1.6 here. I diffed the decision logic in both and it is identical, so what you are seeing on 1.5.2 is the same thing 1.6 will do. The only 1.6 difference is that the WATCHDIGEST env var goes from deprecated to rejected at startup. And to be blunt about 1.5.2: that env var is already a no-op there. It prints the deprecation warning and is never consulted in the digest decision, so do not bother reaching for it as a global switch, it was not one even before 1.6.

On pinned tags getting digest checks: that is intentional, not a bug. Publishers rebuild and republish the same tag constantly, mostly for base image security patches. 18.4-alpine today is often not the same bytes as 18.4-alpine a month ago. The digest check is what catches those rebuilds. It never moves you across versions, a pinned tag stays pinned, it only tells you the same tag was republished. Seeing several images flag digest updates in the same week is normally legit, an alpine or debian base rebuild ripples through a lot of downstream images at once (you have both alpine and bookworm variants in that list, which fits).

One sanity check though: apply one of those digest updates and watch whether it comes straight back. If the same container shows a digest update again right after updating, that is not a republish, that is a false positive and I would want an issue for it with the image name.

For turning it off, the options on 1.5.2 are the same ones I described above for 1.6: dd.watch.digest=false per container, or one imgset per image, e.g. DD_WATCHER_LOCAL_IMGSET_MYAPP_IMAGE=ghcr.io/some/image plus DD_WATCHER_LOCAL_IMGSET_MYAPP_WATCH_DIGEST=false, which covers every container running that image. Imgset matching is by exact image reference, no wildcards, so there is still no single "off everywhere" switch. Container labels beat imgsets, so the inverse of your setup also works: imgset false on a shared image plus dd.watch.digest=true on the one container you do care about.

[scttbnsn]

Follow-up: your report made me audit the whole digest comparison pipeline, and it did turn up one real bug, now tracked as #669. Short version: drydock trusts the first entry of the local image's RepoDigests array, and Docker can leave stale entries at index 0 after pull/retag cycles. When that happens you get a digest update that is flagged forever, and applying it does not clear it.

That gives you two quick checks that tell us exactly which case you are in:

1. Apply one of the digest updates. If it clears and stays cleared, it was a genuine same-tag republish and everything is working as designed. If the same container flags again immediately, it is getRepoDigest() trusts RepoDigests[0], anchoring digest comparison to a possibly-stale manifest #669.
2. For a flagged container, run docker image inspect <image> --format "{{.RepoDigests}}". More than one entry with a stale one first is the getRepoDigest() trusts RepoDigests[0], anchoring digest comparison to a possibly-stale manifest #669 precondition.

To be clear, several images flagging in the same week is still most likely just base-image rebuilds. But if either check above points the other way, drop a note on #669 with the image name and inspect output and that becomes the repro.