Ignoring unwanted Terraform attribute changes

Post by shooker435 » Thu, Mar 27, 2025, 8:48 PM UTC

mrmattyboy wrote: post #7

RulerOf wrote: post #6

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 expla…

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'…

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...

Post by zanecodes » Thu, Mar 27, 2025, 9:32 PM UTC

shooker435 wrote: post #11

mrmattyboy wrote: post #7

Earlier quoted context omitted.

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'…

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...

Similarly, older versions (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.)

Re: Ignoring unwanted Terraform attribute changes

Re: Ignoring unwanted Terraform attribute changes