No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I just use an environment variable for this exact use-case. Our CD pipeline tags the outgoing image with the current build/release number, and I set an environment variable `DOCKER_IMAGE_TAG` or something to that build/release number on the pulumi step. Pulumi uses that as the image tag.

You could still use the `latest` tag if that has value in your image repo, since they can have multiple tags. But I wouldn't have your task definition reference the `latest` tag but rather a more permanent tag, otherwise you can't really rollback to a previous image version by just dropping back your task definition revision.

What we do is have a stack specific config variable `dockerImage` which we commit inside the CD job. Another job watches the pulumi config and applies it

What is nice about that too is rollback is simply reverting to the last version of that line.

that works too. We personally don't like that a runtime-input use case needs to make changes to the config file, so we went the environment variable route

You can use `git describe` for this sort of thing too. Your PR-merging logic can add a tag to git, and all future steps in your pipeline can use `git describe` to leverage that git tag easily.

It has to be an annotated git tag though, created using `git -a`