https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
b
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.
a
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.
b
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
l
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
3 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by