[RulerOf]

I've never used this provider, and while I do think you're right that the provider probably shouldn't change the attribute on you, the docs for the `docker_container` resource[1] suggest populating the `image` argument with the `image_id` attribute of a `docker_image` resource[2].

This should give you a location to stick in the friendly name of a container that won't get clobbered by the provider.

I do like the explanation you provided though, because this is the kind of puzzle you can't really solve with Terraform until you've run into it. I've never used the `replace_triggered_by` feature.

[1]: https://registry.terraform.io/providers/kreuzwerker/docker/l...

[2]: I was originally expecting `docker_image` to be a data source, but the resource seems to be the recommended method for this, and I didn't wrap my brain around the differences between the data source and the resource before writing.

[mrmattyboy]

Good point - I hadn't actually looked massively hard into solving it with this provider - I had to do it again for another use-case recently and decided to blog about it (and also try my hand at a short post).. but used this example from a while ago because it seemed much more relatable than the latest encounter :D

I guess, assuming you're not building the image, whether you use the data source of image probably isn't too important (assuming the data source is able to lookup images that aren't present on the local machine :thinking:).

Edit: and now I've seen that in the docker image resource, they reference using the data source to be able to track remote image SHA changes, in order to trigger an image re-pull :doh:

Feels like we've gone full-circle with this :D

[shooker435]

Great find and post.

I've run into this exact thing. Luckily rebuilding a container doesn't cause downtime for us and 99% of our changes require rebuilding an image, so I've just left it as is...

It is annoying though when we make a small infra change and have to wait for the container image to build...

[zanecodes]

Similarly, older versions (<3.0) of the provider had a `build` attribute for the `docker_registry_image` resource, which made it possible to build and publish an image to a registry, without causing unnecessary rebuilds if there was no local version of the image on the build host.

Now you have to use the `docker_image` resource to build a local image on the build host, and then use the `docker_registry_image` resource to publish it to the registry. In a CI/CD scenario with ephemeral runners, there will never be a local version of the image on the build host, so the image will always be rebuilt on every Terraform run, even if there are no changes to it.

It's a tricky problem to solve from a provider design standpoint, since building a Docker image necessarily creates a local Docker image on the build host, which may not be a desirable side effect for the `docker_registry_image` resource to have and raises other design questions with no universal answers (Should it delete the local image after building? What if there's already a local image with the same name/tag, but it's not in the Terraform state; should it use the existing one or build a new one and overwrite the existing one? If the `docker_registry_image` resource is removed, should any corresponding local images also be delete? etc.)

[captn3m0]

I run docker over terraform on my homeserver and use exactly this invocation.