Hi all. I'm using Pulumi self-hosted and really struggling to figure out a sane GitHub deployment workflow. I have an application I want to build to a Docker image, and then deploy that Docker image via Pulumi. Would some people be able to share how they achieve that? I'm struggling with chicken-and-egg problems with generating Docker tags, and updating Pulumi config with those tags.

What exactly is your chicken-and-egg problem? The general approach looks something like this:

MY_TAG = "abc123"
docker build ... -t my-image:$MY_TAG
docker push my-image:$MY_TAG
pulumi config set image_tag $MY_TAG
pulumi up

Do you bother committing the config file change? I think that's one place where I get a chicken-and-egg problem. I want the Docker tag to contain the commit hash, but if I also want to write that config value to Pulumi config and commit it, then the hash will change.

The goal is usually to have a 1:1 link between the image tag and the code it contains. As long as the configuration file is not part of the Docker build, I think it's fine to commit the Pulumi configuration afterwards. Consider the common situation where you store your Pulumi code in a different repository than the code you build your Docker image from: I assume you'd tag the Docker image based on the commit hash of the code repository, not based on the commit hash of the infrastructure repository. You can also not commit the configuration in CI and update your local configuration retroactively using

pulumi config refresh

. But once you commit the config, you'll still be one commit ahead.

Yeah, I guess part of the problem is that my Pulumi code and config is in the same repo as the application being deployed. So updating Pulumi config generates a new commit, which is a new app version.

I think you'll have to solve this problem logically, because there's no way you can escape this chicken-and-egg problem with any proper hash function. It's as recursive as it gets 😉 Expanding on the example above, the overwhelming majority of applications consist of components that are versioned independently. So it should not be a problem that "app version abc123" consists of, among other things, "image:def546". Even in a monorepo world, you don't have to rebuild/re-release a component if it hasn't changed.