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

So I keep getting spurious diffs from e.g. dep v0.5 vs 0.4.1

<@UBAJ7TD53> I seem to remember that you were looking for something like this as well. Am I right? Did you ever get anywhere?

I have been slowly containerizing anything that causes me platform-dependent pain

but so far I have only containerized the protobuf stuff.

Other people have tried to write containers for pulumi/pulumi and pulumi/pulumi-kubernetes, but nothing has been checked in.

Didn't <@U87DZN4MT> do this as part of his CI container work? Ideally we would layer any CI-specific specializations on top of a base simple Pulumi CLI base image.

Uh, I’m not sure he did? Could be wrong.

I think that <@UB8A66MPS> is asking if we have a container definition for our build environment (e.g what we execute in on Travis).  The answer for that is that we do not, since we do not use docker in Travis.  We do have <https://github.com/pulumi/scripts/blob/master/ci/install-common-toolchain.sh> which is the shell script we run on Travis.  You could probably use that as the seed for a developer environment, but we have not done that.

The thing Joe is referring to, I think, was the example we did for CodeShip Pro where they force builds to happen in docker containers.  All that work was was putting Pulumi in a container (see: <https://github.com/pulumi/codeship-example/blob/master/Dockerfile>).  But this did not try to define an environment which could be used to build Pulumi itself.

Ah I had assumed they would be the same thing: 1) a base container that builds Pulumi and 2) a derived container that uses the result of that built Pulumi. I can see why they could be different things. I will point out that they don't necessarily need to be, however, and that to simplify our lives it may be worth thinking of them as the same thing. The only overhead I can see is that the Go toolchain is needed in one but not the other.