Handle containers that need a custom build step?

[verybadsoldier]

Hi there, I have one case in my container zoo that is a bit special (probably not too special though): A container that has a build command inside the docker compose file. So, when a new version comes out then the arg has to be updated and the image has to be built. The file looks like this:

  telegraf:
    build:
      dockerfile: telegraf.Dockerfile
      args:
        TELEGRAF_VERSION: "telegraf:1.39.3-alpine"
    image: telegraf:1.39.3-alpine-vbs

Just for information, this is the Dockerfile (it just adds the ipset binary to the base image):

ARG TELEGRAF_VERSION

FROM ${TELEGRAF_VERSION}

RUN apk update && \
    apk add ipset sudo iptables

# Add sudoers entry for telegraf to run ipset without password
RUN for f in /usr/sbin/ipset /usr/sbin/xtables-nft-multi; do setcap cap_net_admin,cap_net_raw,cap_dac_read_search+eip "${f}"; done

I thought about having a command trigger in drydock that runs a custom script when a new base image is available to handle the situation but it seems drydock is not watching my local custom image:

Any ideas what I can do about it? This could also be a feature request if needed :) Thank you

[Labeeb2339]

Drydock will not notice this change from the Compose file alone.

The current watcher compares the running container's image: reference against registry metadata (tag/created date, and digest when digest watching is enabled). The Docker action then pulls the new image; it does not execute the Compose build: step. The command trigger is also attached to an update notification, so it is not a Dockerfile/base-image file watcher.

For this setup, use a build pipeline outside Drydock:

1. Detect a new Telegraf base image (Renovate/Dependabot or a scheduled CI job).
2. Rebuild the Dockerfile with the new TELEGRAF_VERSION.
3. Push the resulting image to a registry, preferably with a new immutable tag or updated digest, for example ghcr.io/<org>/telegraf-with-ipset:1.39.3-vbs.
4. Point Compose's image: at that published image and opt the service into Drydock's Docker/Compose trigger.

Drydock can then see the published tag/digest change and pull the rebuilt image. If the custom image remains local-only, keep the rebuild/recreate operation in the external watcher/CI job (for example docker compose build telegraf && docker compose up -d telegraf); Drydock has no registry event to act on in that case.

This follows the current docs/source:

• Docker trigger: https://github.com/CodesWhat/drydock/blob/main/content/docs/current/configuration/triggers/docker/index.mdx
• Command trigger: https://github.com/CodesWhat/drydock/blob/main/content/docs/current/configuration/triggers/command/index.mdx
• Update eligibility (tag/digest comparison): https://github.com/CodesWhat/drydock/blob/main/app/model/update-eligibility.ts

[verybadsoldier]

Ok sure, that would work but that is quite some manual complexity in my opinion.

Would it be possible to extend drydock in that regard to support this case?

There is already the option "dd.registry.lookup.image" which allows us to manually reference a registry image, right? So, maybe drydock could watch the container even if it is a local build when this option is set and then monitor the image mentioned in that option? Still the transform option could be used to transform the locally assigned image_name to extract a proper semver version.

Like:

  telegraf:
    build:
      dockerfile: telegraf.Dockerfile
      args:
        TELEGRAF_VERSION: "telegraf:1.39.3-alpine"
    image: telegraf:1.39.3-alpine-vbs
    labels:
      - dd.watch=true
      - "dd.tag.include=^\\d+\\.\\d+\\.\\d+-alpine$$"
      - "dd.tag.transform=^v?(\\d+\\.\\d+\\.\\d+)-alphine-vbs$$ => v$$1"
      - "dd.registry.lookup.image=telegraf:1.39.3-alpine"

So maybe the watcher in drydock could be triggered with this and then we can run a command trigger with it to do the manual build step.

[Labeeb2339]

Thanks for the concrete proposal. I checked the current watcher path: dd.registry.lookup.image is used to redirect registry metadata lookups, but locally built images are explicitly marked with isLocalImage when the live image has no RepoDigests, and findNewVersion() returns before querying the registry. So the label alone cannot enable this today. Supporting it would need a separate, explicit local-build mode that uses the lookup image only for version discovery while keeping the local image: as the deploy identity and routing the update to a command or Compose rebuild instead of pulling the lookup image. That separation matters for safety. Two details in the example would also need correction: dd.registry.lookup.image=telegraf:1.39.3-alpine is pinned to one base tag, so it would not discover later base releases unless the lookup reference follows the intended release stream; and the transform example says alphine rather than alpine. I agree this is a reasonable feature request. A good issue would include the Compose file, the local-image/no-RepoDigests state, the desired lookup-to-rebuild mapping, and tests covering that Drydock never replaces the locally built deploy image with the lookup image.

[scttbnsn]

Short answer: it cannot work today, and your labels are not what stops it.

The watcher gives up before the lookup label is ever consulted. findNewVersion checks container.image.isLocalImage and returns early with Locally-built image (no repository digest) — registry not queried. That flag comes straight from the live docker inspect: no RepoDigests means locally built. An image produced by docker compose build that has never been pushed or pulled never has any, so it always trips that gate no matter what labels you set. dd.registry.lookup.image is only read further down, on the path that never runs for you.

That gate is deliberate. It exists so local images do not fire anonymous 401s and 404s at the registry and get counted as watch errors. So what you are asking for is a code change, not a config one.

Two things in the labels anyway, for when this does become possible:

• alphine is misspelled in the transform. A transform whose pattern does not match returns the tag unchanged, so it is a permanent no-op.
• dd.registry.lookup.image=telegraf:1.39.3-alpine has no slash in it, so it gets parsed as a bare registry hostname rather than an image reference. It would want library/telegraf.

The part worth thinking through before building it: if the watcher did see an update, the Docker action would pull upstream telegraf and recreate your container with the stock image, which drops your ipset layer. So detection alone is not the feature. It needs detection plus a command trigger that runs your build, with the Docker action excluded for that container. Your instinct about the command trigger was right, it just needs the gate solved first.

The request itself is reasonable and I am keeping it open. Watching a local build against a declared upstream base is a real gap, and the dd.registry.lookup.image label is the natural place to hang it. No promises on timing.

@Labeeb2339 thanks for the detailed answer above, the external CI pipeline is the correct workaround today.

[verybadsoldier]

Okay, thank you. Appreciate it.

[scttbnsn]

No problem.

I have written this up as a feature request rather than leaving it buried in the thread, since the shape is clear enough to build: a local-build mode where a lookup reference drives version discovery only, the local image: stays the deploy identity, and the update routes to a command or a compose rebuild instead of a pull. No date on it.

The pull-and-replace behaviour is the part that has to be solved first. Without that, a working update would quietly swap your patched image for stock telegraf, which is worse than not detecting the update at all.